Википедия:Форум/Архив/Предложения/2017/11

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Архив форума
Правки нежелательны

Эта страница — часть архива форума Википедии.

Пожалуйста, не редактируйте эту страницу!
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

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

Это наверняка где-то обсуждалось, но не знаю где. Речь о том, что карточки в настоящее время слишком ограничены в своём наполнении. Они имеют фиксированые параметры, которые фиксированы непонятно кем и для чего. Примеров каждый из Вас может привести миллион. Допустим, в карточке для Стоун, Шэрон я хочу указать её рост? Мне в этом отказано. Детей? Отказано. Но кто где и почему решил, что для статьи о ней это не важно? Я открываю статью в надежде узнать её рост сразу же, я не хочу выискивать его в куче текста, тем более, что его там нет. Предлагаю создание универсального щаблона, который включал бы вообще все параметры. На странице описания сделать подробное деление категорий, которые могли бы быть использованы, рекомендации и т.д. По аналогии с шаблоном {{Публикация}}. --Алый Король 04:41, 26 ноября 2017 (UTC)

  • Очень сложный процесс. И технически и организационно. Но Путник тестирует такое на малых разделах. ShinePhantom (обс) 05:29, 26 ноября 2017 (UTC)
  • Но вообще, чтобы указывать рост там, где его не указывалось - консенсус на это быть должен, независимо от технических возможностей ShinePhantom (обс) 05:31, 26 ноября 2017 (UTC)
  • Смысл карточки, в числе прочего, в том, чтобы показать в табличной форме те параметры объекта, которые отличают его от других объектов того же типа. Для этого у всех объектов одинакового типа должны быть в карточках одни и те же параметры. Если параметр нехарактерный для объектов данного типа, то не надо его вставлять в карточку. Vcohen (обс.) 07:58, 26 ноября 2017 (UTC)
  • Для того, чтобы заносить ВСЕ параметры объекта, есть Викиданные. Карточка нужна для краткого перечисления наиболее важных параметров.--Tucvbif???
    *
    08:45, 26 ноября 2017 (UTC)
  • А если кому-то захочется радиус кривизны члена Билла Клинтона в карточку, всем политикам, независимо от пола, его укажем? Фил Вечеровский (обс.) 10:49, 26 ноября 2017 (UTC)
  • Достаточно странное рассечение сознания. Когда я утверждал, что в карточку учёный не стоит добавлять военные награды, мне отвечали: "это же один человек, как вы можете отказать ему в части наград", а если вдруг у Билла Клинтона докторская защищена по археологии, или же член 30 см, то нет, это не важный параметр. А наличи е известной дочери или отца важный? Его я мог указать? Кто это вообще определяет, что важно, а что нет? --Алый Король 13:08, 26 ноября 2017 (UTC)
  • Лучше награды удалить.--Abiyoyo (обс.) 13:15, 26 ноября 2017 (UTC)
  • Техническая реализация предложения весьма сложна, а организационная натолкнётся на тот факт, что существуют поля, по которым было принято специальное решение сообщества о запрещении их в карточках (всех или в конкретных), например "национальность" (в специфическом русскоязычном значении этого слова - ethnicity). MBH 13:23, 26 ноября 2017 (UTC)
  • Когда-нибудь, будет только одна универсальная карточка и все данные для неё - в ВД. Когда-нибудь... И тогда начнется другая битва - в что в ней представлять. Как минимум, появятся противники и сторонники наград. :-) Не говоря уже об остальном. --Gennady (обс.) 16:17, 26 ноября 2017 (UTC)
    • Угу. С флагами Римской империи и прочими невыразимыми прелестями. Как же я долго доказывал викидатчикам, что Рубенс - не бельгиец, а подданный Испанских Нидерландов... Ответ тоже был универсальный: «ну, мне как бы история не интересна…»--Dmartyn80 (обс.) 20:49, 27 ноября 2017 (UTC)
      • ну так обычно приходят и говорят: "неправильно!". А как правильно - не говорят. И предлагают самому изучить, к какой стране относилась та или иная деревня в 13 веке. А у Рубенса же Испанские Нидерланды и стоят? ShinePhantom (обс) 10:41, 28 ноября 2017 (UTC)
        • В конечном итоге, да. Но сколько лет он простоял с Бельгией?--Dmartyn80 (обс.) 11:33, 28 ноября 2017 (UTC)
          • Издержки есть во всём! --Gennady (обс.) 11:50, 28 ноября 2017 (UTC)
            • Это не самое страшное в случае с викиданными. Самое ужасное - это вездесущая Немецкая публичная библиотека, "главный АИ" по датам рождения всех писателей и рисователей. Ну и имбд в качестве источника по актерам. --Алый Король 11:56, 28 ноября 2017 (UTC)
              • пока она зачастую единственный корректно указанный источник - от нее избавляться или как-то подавлять большого смысла нет. Потому что вторая по популярности тема обсуждений про ВД - там не указаны источники!!! ShinePhantom (обс) 12:16, 28 ноября 2017 (UTC)
      • Вот в третьей же просмотренной карточке известных художников — уже прекрасное. У Рафаэля страна — Италия. Вот просто Италия. Зато с источником! А, вот и у Микеланджело тоже. Но без источника. AndyVolykhov 12:28, 1 декабря 2017 (UTC)
        • @AndyVolykhov: Это решаемо. Таких проблем и у нас хватает. Правда, обычно наоборот — по менее значимым персонам. И самое важное, что на это почти всегда находятся источники. Да и не раз на форумах звучали предложения вида «не хочу разбираться в флагах и странах, давайте ставить нынешние». Так что в перспективе Викиданные скорее избавляют от таких проблем, чем являются их источником. Но да, работы ещё непочатый край. — putnik 12:28, 5 декабря 2017 (UTC)

Господа, где правильно было бы обсуждать движок и его «побочные» перспективы?[править код]

Я хочу расторомошить утихшую тему Викикодии. Этого просто не может быть, чтобы сама идея была неправильной. Не может быть потому, что эта «идея» может трактоваться предельно широко, следовательно, существует некоторое количество правильных трактовок и бесконечное поле неправильных. То есть если что-то не получилось, то это только потому, что сделано неправильно, следовательно, надо делать правильно. Один провал ни о чём не говорит, когда речь о настолько расплывчатой теме. Просто ткнули не в то место.

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

Предложение номер один: хорошенько подискутировать в специально отведённом месте, благо тут люди в основном разбираются в тонкостях, а затем уже конкретную продуманную реализацию вынести на суд ну фонда Викимедиа, хотя бы. 81.195.26.51 13:44, 23 ноября 2017 (UTC)

Обсуждения движка - это, наверное, где-то в MediaWiki. — Igel B TyMaHe (обс.) 14:30, 23 ноября 2017 (UTC)
А в русскоязычном междусобойчике где-нибудь предварительно можно или у нас нет кворума разбирающихся людей? Ну то есть понятно, что он есть, я в смысле того, что не сформировалось постоянного обиталища. 81.195.26.51 15:19, 23 ноября 2017 (UTC)
Всё равно на MediaWiki. — Igel B TyMaHe (обс.) 07:51, 26 ноября 2017 (UTC)
Точно? А может, на странице, оставшейся от прошлой попытки? Потому что на MW как-то больше обсуждения по технической стороне, когда уже конкретно ясно, что именно делается. А на уровне «вот хотим что-то Замечательное, но не можем понять, что хотим» и «мы не хотим опять получить Дохлое» КМК лучше как раз на WM. Т. е. там определиться с ТЗ и ТТХ, а потом, если что-то выкристаллизуется (оххх и сомнения же у меня…) тащить это на MW с вопросами, как это реализовать.81.195.16.71 22:46, 28 ноября 2017 (UTC)
Ладно, если аргументов за и против нет, то создаю как считаю нужным. 81.195.31.223 15:54, 18 декабря 2017 (UTC)

Случайно обнаружил эту страницу. Очень хороший текст, который в рамочке и со смайликом (Внимание! Перед созданием темы...). Предлагаю этот текст добавить в MediaWiki как пожелание перед созданием любой темы на форуме или странице обсуждения статьи или участника. Лично себе я обязательно этот текст добавлю. Ваше мнение? Oleg3280 (обс.) 20:02, 22 ноября 2017 (UTC)

в смысле - поставить этого монстра перед текстбоксом, чтобы текстбокс вообще уплыл за пределы экрана? Спасибо, но нет.— Igel B TyMaHe (обс.) 09:23, 23 ноября 2017 (UTC)

Поскольку в категориях невозможны редиректы, проблему перенаправления с "неправильного" названия категории на "правильное" когда-то решили единственно возможным на тот момент способом - созданием страницы категории с неправильным названием и вешанием туда шаблона, что не надо заполнять эту категорию, а надо - категорию с правильным названием. См. Категория:Автобус и Категория:Автобусы. Сейчас таких категорий-редиректов у нас 529 штук. Описанная схема создаёт, например, следующее неудобство: при добавлении категории хоткатом невозможно прозондировать, какое название правильное, так как существуют обе категории (я обнаружил проблему, когда попытался добавить в статью Дуобус категорию "автобус" или "автобусы" и обнаружил, что согласно хоткату есть и та, и та). Кроме того, участник, добавляющий статью в категорию хоткатом, легко может добавить её в "неправильную" категорию, т.к. видит лишь, что такая категория существует. С тех пор, как был установлен описанный порядок, появился механизм, позволяющий писать что-то о странице без её создания - эдитнотисы. Собственно, предлагаю упразднить институт категорий-дубликатов, удалить их, а для предотвращения пересоздания повесить на их имена эдитнотисы, указывающие правильное название каждой конкретной категории. Выглядеть это будет так: [1] MBH 12:51, 22 ноября 2017 (UTC)

  • Правильно ли я понял, что это не защита от создания категории, а только сообщение юзеру, создающему ее? Vcohen (обс.) 13:08, 22 ноября 2017 (UTC)
    • Если их защищать, эдитнотис не будет виден (он показывается только в режиме редактирования). MBH 13:24, 22 ноября 2017 (UTC)
      • То есть я правильно понял, что защиты как таковой нет? Тогда что будем делать с юзерами, которые невнимательно читают? С ботами, которые еще никак не читают? С автоматическим созданием категории со старым названием при переименовании? Vcohen (обс.) 13:28, 22 ноября 2017 (UTC)
        • Боты не создают категории. Какое автосоздание, речь о категориях, давно признанных неверными названиями (типа К:NASA), с них никто ничего не будет переименовывать, т.к. категории на этом месте просто не должно появиться. Не предлагается, чтобы любая переименованная категория становилась редиректом нового типа. MBH 13:34, 22 ноября 2017 (UTC)
  • Упразднить механизм и ничего не вводить взамен. Он, во-первых, почти не используется (500 категорий — это ни о чём, переименованных и неоднозначных на порядки больше; в англовики дубликатов 60 тысяч, а категорий всего в 4 раза больше). Во-вторых, за ним кто-то вообще следит? Я среди категорий-дубликатов вижу категории с включениями статей (что даёт «в-третьих»: механизм не работает). Кто-то это исправляет и как часто?
    А у варианта с эдитнотисом есть множество проблем. Очевидная: категорию-дубликат может создать кто угодно, а эдитнотис не сможет даже удаливший категорию ПИ. Неочевидная: в эдитнотисе уже столько информации, что дополнительный блок никто читать не будет.
    ИМХО, удаление дубликатов с указанием правильного названия в причине удаления плюс механизма отслеживания репостов будет достаточно. ~Facenapalm (обс.) 13:27, 22 ноября 2017 (UTC)
    • Видимость дополнительного блока - не проблема, надо просто сделать его достаточно большим и достаточно красным. MBH 13:34, 22 ноября 2017 (UTC)
  • Вопрос: количество эдитнотисов ограничено? --VladXe (обс.) 13:46, 22 ноября 2017 (UTC)
    • Нет. Один эдитнотис - одно сообщение в пространстве имён MediaWiki, их число не ограничено. MBH 13:48, 22 ноября 2017 (UTC)
      • Тогда требуется механизмы: а) обсуждения, б) сигнал инженерам или администраторам, что эдитнотис надо добавить/удалить в результате обсуждения; в) отслеживания и г) быстрого удаления категорий, созданных вопреки существующим эдитнотисам. К тому выше было написано, что приведённый пример блеклый, розовый фон, как в запрещающих шаблонах, более уместен. Да текст отредактировать. А русский эквивалент «эдитнотиса» есть? --VladXe (обс.) 14:50, 22 ноября 2017 (UTC)
        • а) ОКАТ, б,г) чаты запросов к администраторам, в) можно бота запилить (я могу). Разумеется, шаблон будет другой, это так, пример. По-моему, сам "эдитнотис" нормальный термин, у нас почти все вики-термины нерусские, а многие из русских имеют очень иной смысл (бюрократы, патрулирование...) MBH 15:28, 22 ноября 2017 (UTC)
          • б) Не пойдёт, нужно что-то наподобие {{Editprotected}}, который можно было б повесить в номинации обсуждения категории с подведённым итогом. г) КБУ О4 разве не подходит? --VladXe (обс.) 15:35, 22 ноября 2017 (UTC)

Предитог[править код]

Предложение принимается в откорректированной форме, предложенной Фейсом: категории-дубликаты удаляются, а вместо эдитнотисов направление на корректную категорию указывается в обосновании удаления, после чего удалённая категория полузащищается от создания. Бота для этих удалений, помещающего название-цель редиректа в обоснование удаления, я написать могу. MBH 15:34, 8 декабря 2017 (UTC)

Итог[править код]

Так и сделаем. MBH 06:05, 23 декабря 2017 (UTC)

Номинации ВП:КОБ и ВП:КР по месяцам[править код]

Добрый день! В продолжение темы на Ф-О. Коллеги, я понимаю, что можно спорить про ВП:КОБ и ВП:КР бесконечно, но что насчёт конкретного вопроса про объединение номинаций по месяцам (или неделям)? По-моему, 20-30 номинаций на странице — вполне приемлемо, и внимания будет несколько больше. P.S. Остальное на Ф-О, пожалуйста. Викизавр (обс.) 23:24, 21 ноября 2017 (UTC)

Формат форума правил[править код]

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

  1. Перенос всех обсуждений на Википедия:Обсуждение правил. Радикальный вариант — оставить форум правил для анонсов обсуждений правил, а все собственно обсуждения переносить на отдельные подстраницы на Википедия:Обсуждение правил.
  2. Перенос больших обсуждений на Википедия:Обсуждение правил. Менее радикальный вариант — все темы, которые выходят свыше порога в x Кб, переносятся на отдельную подстраницу на Википедия:Обсуждение правил и обсуждаются впоследствии там (на форуме правил остаётся авторский анонс об обсуждении). Реализован мной полчаса назад с темами размером свыше 200 Кб, что позволило уже снизить размер форума почти наполовину. То, что мы принимаем за «x», надо выяснять (и прошу всех высказывающихся, даже не за этот вариант, написать, что они считают большой темой, достойной переноса с форума).
  3. Ваш альтернативный вариант.

Первые два варианта — это только то, что приходит на ум мне, предлагайте альтернативные. Вариант «ничего не делать, мне нравится редактировать страницы в полтора мегабайта» не является жизнеспособным, даже если вам действительно это нравится. stjn 17:46, 21 ноября 2017 (UTC)

  • Любой, кому мешает разросшееся обсуждение, может перенести его на подстраницу. И следить проще будет. —Good Will Hunting (обс.) 17:54, 21 ноября 2017 (UTC)
  • Дельное предложение. Особенно если учесть, что существует физическое ограничение Викидвижка на максимальный размер страницы (1,5 - 2Мб). Когда он будет достигнут, страница просто перестанет работать, а может даже и движок вырубится. -- Q-bit array (обс.) 18:18, 21 ноября 2017 (UTC)
  • Вообще в теории всегда считалось, что на форуме — просто общее обсуждение, на ОБП — уже годовые, подготовленные проекты. И в этом теоретическая разница двух мест. С другой стороны сейчас Ф-ПРА используется как свалка всего. Поэтому в теории правильный путь — на Ф-ПРА просто общий треп, на ОБП — конкретные, готовые проекты, имеющие какие-то шансы быть принятыми. Но это теория.--Abiyoyo (обс.) 18:52, 21 ноября 2017 (UTC)
  • Третий вариант: 1) С Ф-ПРА нужно что-то делать, т.к. реально неудобно 1+ Мб обрабатывать. 2) В то же время согласен с Abiyoy «на ОБП — конкретные, готовые проекты», как минимум прошедшие обсуждение ещё где-нибудь. 3) (сам вариант) Предлагаю внедрить подстраницы для Ф-ПРА, одновременно разгружая сам форум и не перегружая ОБП. Тема / несколько связанных тем достигли порога в размере х кб — вынести её / их на подстраницу, ссылку на которую разместить в чердаке форума. Три месяца нет новых сообщений на подстранице — она переносится любым в спецкатегорию архив. Можно настроить бота на последнее, чтобы через 50 дней он сообщал о предстоящей архивации, а ещё через 10 (если никто не отозвался) — закрытие и удаление ссылки из чердака Ф-ПРА. --VladXe (обс.) 19:25, 21 ноября 2017 (UTC)
  • Второй вариант с обязательным дублированием текущих, живых флудов в «актуально». Retired electrician (обс.) 20:31, 21 ноября 2017 (UTC)
    • @Good Will Hunting, VladXe, Retired electrician: напишите и о том, сколько тогда большие обсуждения. Так хотя бы можно прийти к общему знаменателю по итогу обсуждения, чтобы не было потом конфликтов на пустом месте. Дублирование в Википедия:Обсуждение правил происходит через блок «Обсуждения правил» в том шаблоне. Возможно, стоит убрать там ограничение по высоте, чтобы все было видно и заметно (и, может, увеличить основной текст в шаблоне). stjn 20:52, 21 ноября 2017 (UTC)
      • Вряд ли стоит проводить жёсткую границу; ведь дело не только в массе текста, но и в длительности препираний, и в сложности вопроса по существу. Вполне можно отдать решение на откуп админам - кто первым перенёс, того и тапки. Retired electrician (обс.) 20:58, 21 ноября 2017 (UTC)
      • Для 3-го варианта ИМХО, среднепотолочная «круглая» цифра от 100 до 200 кбайт, но больше склоняюсь к 100 кбайт (для последнего принятого руководства хватило 127 кб, хотя был ещё топик на форуме). --VladXe (обс.) 21:01, 21 ноября 2017 (UTC)
  • А не вернуть ли пока архивацию через месяц неактивности, а не две недели? А то часто стали темы возвращать. Викизавр (обс.) 22:40, 1 декабря 2017 (UTC)
    У меня есть более радикальное переложение. Если размер страницы ВП:Ф-ПРА переваливает за 700 КБ, то автоматически включается полная защита, и администраторам даётся неделя на разгребание обсуждений с немедленной отправкой в архив. Vladislavus (обс.) 05:26, 20 декабря 2017 (UTC)

Установить DynamicPageList в руВики[править код]

Случайно узнал про существование расширения DynamicPageList, которое установлено во всех языковых проектах Викиновостей, например. Оно позволяет получать списки статей по пересечениям нескольких категорий. По-моему, это круто и полезно, может быть, попросить установить в РуВики? Или там какие подводные камни (производительность, нецелевое использование, иное)? --Neolexx (обс.) 14:56, 18 ноября 2017 (UTC)

Впрочем, прямо на странице расширения указано "can be installed on any small to medium sized Wikis (It is known to have scalability issues with very large wikis)". Если это не устаревшая информация, то вопрос снимается, не поставить. --Neolexx (обс.) 15:11, 18 ноября 2017 (UTC)

Статьи о сайтах в ВП[править код]

Нашел я тут инфу на Родоводе. Но она малость не стыкуется с другим АИ. И вот я завис, Родовод - это авторитетный источники или как? Но вопрос собственно ширше. Может стоит сделать либо галочку-звёздочку, либо категорию для сайтов, которые прошли ВП:КОИ и считаются авторитетными в ВП? Логично же. -- S, AV 16:32, 13 ноября 2017 (UTC)

  • Нет, это вики-сайт, следовательно неавторитетный.--Abiyoyo (обс.) 16:48, 13 ноября 2017 (UTC)
    • Вопрос ширше. -- S, AV 04:25, 14 ноября 2017 (UTC)
      • Шире — можно, только не категорию, а список, так как для большинства АИ, рассмотренных на КОИ, статей отдельных нет. Да и вообще нет нужды мешать контент и внутривикипедийные дела. А вот список источников, рассмотренных на КОИ, сделать можно и нужно. --Abiyoyo (обс.) 07:15, 14 ноября 2017 (UTC)
      • ВП:ПС. Найдите проект, заведите страницу "надёжные источники" и заполняйте по своему разумению. Кому не понравится - вычеркнут. — Igel B TyMaHe (обс.) 09:03, 14 ноября 2017 (UTC)
        • Знать бы, как на КОИ определять "источники, которые были признаны авторитетными". Навскидку посмотрел текущие обсуждения и последние архивы, ни одного нет. --Лес (обс.) 15:53, 17 ноября 2017 (UTC)
        • Да, мысль о создании страниц с АИ хорошая. Есть пример реализации на практике: страница по источникам в рериховской тематике — ВП:АЙИ. Там не только надёжные источники, но и ненадёжные, что не менее полезно, как отметил коллега выше. —Alexandrine (обс.) 09:38, 22 ноября 2017 (UTC)

К ограничению номенклатуры stub-шаблонов по тематике[править код]

Данное предложение является развитием обсуждения #Ограничение номенклатуры stub-шаблонов

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

  • географическое/страноведческое (Россия, Мозамбик, Мос.область, Барнаул и т.п.),
  • тематическое (биология, физика, спорт, и т.п.),
  • биографическое (биолог, физик, спортсмен).

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

В части географического/страноведческого дерева:

  1. оно очень хорошо стандартизируется через ISO 3166-1:
    • при этом лучше выбрать alpha-2 (а не alpha-3), ибо коды регионов образуются именно от alpha 2,
    • не ясно, что делать с крупными городами (не являющимися регионами), но это можно решить в частном порядке,
  2. на мой взгляд, имеет смысл наложить при этом следующие ограничения:
    • страна с населением меньше X тыс.жителей, как правило, может иметь только один головной шаблон «страна-stub» без подшаблонов,
    • регион/город с населением меньше X тыс.жителей, как правило, не может иметь собственный шаблон,
    • в качестве планки "X тыс." по некоторой аналогии с ВП:ПНИ#10 и ВП:ПНИ#11 не имеет смысл планка 100 тыс. (а, имхо, точно нужна более высокая - м.б. 1 млн?) (см. также Список стран по населению);
  3. (исключительно личное мнение) я не вижу смысла в шаблонах типа «страна/регион/город-geo-stub» (около 320-330 вариантов), предлагается перенаправить их (переименовать/откорректировать при необходимости) на соответствующие «страна/регион/город-stub».

В части начала ветвления тематического дерева и биографического дерева я бы предложил отталкиваться от укрупнённых групп по ОКСО (от математики к военному делу и спецслужбам) (ну или иного аналогичного и широкого классификатора). На мой взгляд, нужная нам основа в этом классификаторе есть, и она наиболее подходит текущей ситуации со stub-шаблонами (естественно с заменой/разделением некоторых названий на более распространённые в проекте). Alex Spade 11:47, 11 ноября 2017 (UTC)

  • Пока не началось: не считаете ли нужным ограничивать не по внешним абсолютным признакам, а по внутренним википедийным? То есть подробность стабов поставить в зависимость от числа созданных статей темы, а не потенциально возможного числа по указанным выше критериям? Ведь теоретически возможно даже отсутствие статей по какой-то географической теме, но наличие стаба исходя из "абсолютных показателей". Возможна комбинация внешнего и внутреннего критерия (1 млн + "но не менее 5 уже созданных статей" - для четырех статей используется вышестоящий стаб). — Igel B TyMaHe (обс.) 20:43, 11 ноября 2017 (UTC)
    • Имелось в виду, что указанные критерии нацелены на имеющиеся шаблоны с целью их сокращения. Предполагается, что если сейчас нет некоторого шаблона (даже если он соответствует критерия), то эти критерии нельзя применять для его создания. Ну, как-то так. И, да, я согласен, что для критериев видимо следует применять союз «И», то есть возможный stub-шаблон должен соответствовать им всем. Alex Spade 20:56, 11 ноября 2017 (UTC)
    • По окончанию опроса я собирался инициировать тему/подстраницу с эссе/руководством/правилом, регулирующим как критерии существования стаб-шаблонов, так и их формат. ИМХО, обязательный критерий один: у стаб-шаблона должно быть не менее 5 включений, все остальные критерии — допустимые, в число которых могут/должны входить как количество существующих стабов (например, 25 — стаб-шаблон точно разрешён), а так и развитие темы в рувики (например, если по теме существует 100 статей (любых, удовлетворяющих правилам), то стаб-шаблон по теме может быть. По числам надо установить консенсус. --VladXe (обс.) 21:16, 11 ноября 2017 (UTC)
  • Лично мне такое выбор "основных" деревьев выглядит совершенно не очевидным. Почему географические регионы - это отдельная тема, а темы техники, школ, войн, телесериалов, и, скажем, быта - все в одной куче? Почему бы не сохранить уже существующее разделение списков тем Википедия:Шаблоны/Незавершённые_статьи? Или можно держаться поближе к дереву категорий, с верхними уровнями согласно Категория:Статьи? --Шуфель (обс.) 09:22, 12 ноября 2017 (UTC)
    • Пока не подведён итог мини-опроса, глобальное реформирование только в мечтах. Сначала надо определить, а какой стаб-шаблон вообще допустим, что подсчитать, сколько и каких нужно. Исходя из всей совокупности допустимых, будем определять дальнейшую категоризацию. Вдруг консенсус будет на 40 стаб-шаблонов, по числу тем в Ш:rq? --VladXe (обс.) 10:00, 12 ноября 2017 (UTC)
    • Вы тут не поняли мой тезис: географическое и биографические деревья выделы потому, что они образует пересечения с как между собой, так и с тематическим другими. Т.е. у нас есть гораздо чаще встречаются стаб-шаблоны типа регион-тема-stub или профессия-stub (профессия = тема-биография) или регион-профессия-stub, но намного-намного реже варианты тема1-тема2-stub (типа НС о телесериалы о войнах). Alex Spade 15:58, 20 ноября 2017 (UTC)
  • Внимательно прочитал все представленные обсуждения и не понял самого главного вопроса: "А зачем ???". Зачем удалять шаблоны и вообще как-то их ограничивать в использовании количеством включений или тематикой ?? Из обоснований нашел реально только два: 1) "Мне не нравятся плашки", 2) "Есть желание организовать шаблон по пересечению стаб-шаблонов, но их количество мешает". По первой причине мне сказать нечего, мне тоже многое не нравится но я как-то умею держать свои порывы при себе, а по второй причине - можно создать такие шаблоны и без накладывания каких-либо ограничений на тематики/количество/включения стаб-шаблонов. Нет ничего плохого в их количестве, пусть авторы ставят их как им нравится, это только помогает в написании энциклопедии. Т.е ни одной реальной причины не приведено, при этом искусственные ограничения наверняка отрицательно скажутся на атмосфере написания энциклопедии. Поэтому (−) Против данного предложения. TenBaseT (обс.) 19:06, 20 ноября 2017 (UTC)
    • TenBaseT, у меня к вам большая просьба: если вы не занимаетесь каким-то направлением работы и не понимаете, почему множество участников в теме не первый год говорят о проблеме, лучше просто пройти мимо. Ваши «против» тут выглядят очень неконструктивно. Сначала — разобраться, потом — говорить. Это правило номер один. Причин много, они неоднократно указывались. Повторять в сотый раз нет сил. Когда так делают новички или иные сомнительные участники — это еще можно понять. Когда так поступают те, кого даже арбитром избирали не раз, — вызывает недоумение и только. Использование красных кружочков в реплике тоже нежелательно. Они раздражают. Опытные участники так обычно не поступают. --Abiyoyo (обс.) 19:58, 20 ноября 2017 (UTC)
      • Коллега Abiyoyo, а я думал Вы меня знаете - я обычно ничего не делаю "просто так, чтобы вызвать недоумение или раздражение" :) Еще раз повторю - я вполне готов разобраться, но ни одной ссылки на состоявшиеся обсуждения с релевантными аргументами я не нашел. Дайте мне ссылку и я изучу данную тему "более глубоко", раз Вы считаете что я недостаточно в курсе происходящего. Подчеркиваю, пока я ни одного аргумента (кроме указанных мной выше) не нашел ни в одном из обсуждений. TenBaseT (обс.) 20:58, 20 ноября 2017 (UTC)
        • Аргументы были еще много лет назад. Большая нагрузка на поддержку инфраструктуры, а также необходимость помнить на память (или все время сверять по справочнику) 2000 кодов шаблонов. См. описание проблем тут: Википедия:Опросы/Технические и организационные проблемы stub-шаблонов#Порождаемые проблемы.--Abiyoyo (обс.) 21:08, 20 ноября 2017 (UTC)
          • Как Вы понимаете коллега, ТЕХСТАБ я видел и помню (и даже подписывал решение АК по нему). Как Вы понимаете, по тем аргументам не было и нет консенсуса до сих пор, и не все аргументы того опроса являются проблемой (как и было указано в том опросе некоторыми участниками). Я уж не говорю об "Don't worry about performance". В любом случае, начинать снова обсуждение данной темы, даже не упомянув тех аргументов и не рассмотрев их в предложении о начале реформы стаб-шаблонов - не самая лучшая идея. Самым лучшим вариантом будет созданием нового опроса, со ссылкой на ТЕХСТАБ и анализом аргументов того опроса уже в преамбуле нового опроса. Разумеется с итогом, основанном на подробном разборе аргументов. TenBaseT (обс.) 21:25, 20 ноября 2017 (UTC)
            • Речь идет о нагрузке на участников, а не о производительности аппаратного обеспечения. Проблемы — не аргументы, это факты. Многие говорят о проблеме, значит проблема есть. Считаете, что нужен еще один опрос — проводите. И подведите итог, которым все окажутся довольным. Вот тогда я поучусь у вас. На примере. Оспаривать и отменять легко, делать сложно. Википедия — не о том, чтобы отменять. Она о том, чтобы делать. Впрочем, сейчас этим занимаются другие, мне точно недосуг.--Abiyoyo (обс.) 22:32, 20 ноября 2017 (UTC)
              • Коллега Abiyoyo, я частенько поддерживаю Ваши предложения, но далеко не всегда поддерживаю способы их достижения, в виде быстрого кавалерийского наскока и если сразу не получилось - то никак. В данном случае это не "делать", а "отменять существующее много лет", что больше подходит под "Оспаривать и отменять", тогда как я лишь настаиваю на сохранении статус-кво до выяснения глобального консенсуса сообщества, который до сих пор не найден, при этом попытка запустить какие-то изменения не кажутся мне нормальным способом внесения изменений в ВП. TenBaseT (обс.) 08:49, 21 ноября 2017 (UTC)
                • Так не я запустил же. Я только поддержал, причем даже не во всем согласен с самыми активными. Но в любом случае в том и дело, что хоть тогда, хоть сейчас абсолютное большинство принципиально поддерживает, что видно из голосования на этом форуме. Все видели, все могли отписаться. Запускать обсуждение нужно, если есть несогласные. Они вообще есть? Не видно особо. Вики — это быстро, а не годами обсуждать мелочевку. Вопрос технически сложный, а цена — мелочь. Это не что-то принципиальное, чтобы обсуждать до вечности. Никакой жизни не хватит.--Abiyoyo (обс.) 08:57, 21 ноября 2017 (UTC)
                  • "абсолютное большинство" - это 8 человек из 200-250 активных участников ? Не смешно. "Вики — это быстро" - вот это и есть "кавалерийский наскок", поиск консенсуса в таком сообществе как Вики - дело медленное, спокойное и желательно без потрясений. Если Вам так действовать скучно, это не означает что так действовать неправильно. "Это не что-то принципиальное" - удаление и перетряска 2000 шаблонов, затрагивающих 400 тысяч статей - это "мелочь" ???? И не надо обсуждать "до вечности", нормальным опрос занимает пару-тройку месяцев, после чего месяц на утрясение подробностей и их утверждение и т.п., вполне можно в полгода уложить все действия от начала до конца. TenBaseT (обс.) 10:28, 21 ноября 2017 (UTC)
    • Abiyoyo, разрешите напомнить очень мудрую фразу по поводу кружочков: не говорите, что мне делать и я не скажу, куда Вам идти. TenBaseT, Ваша реплика уже бессмысленна, потому что 3 темами ниже зафиксирован консенсус о реформе стаб-шаблонов. А эта тема — всего лишь реализация этого консенсуса. --VladXe (обс.) 20:06, 20 ноября 2017 (UTC)
      • Я вам другое напомню: уважайте тех, кто вокруг вас. Если людей что-то раздражает — постарайтесь не делать этого. Хотите посылать — ок. Вас тоже пошлют при любом удобном случае. Только и всего.--Abiyoyo (обс.) 20:09, 20 ноября 2017 (UTC)
        • Не хочу, но и «строить» оппонента очень не конструктивно. Дали ссылку на консенсус и всё стало на свои места. Ещё предложение — прекратить дуальные прения на этом или перейти на СО любого из нас. --VladXe (обс.) 20:12, 20 ноября 2017 (UTC)
      • "зафиксирован консенсус о реформе стаб-шаблонов" - ссылочку не дадите на "фиксацию консенсуса", на итог обсуждения с подробной аргументацией ? Разумеется, прежде чем написать комментарий выше, я внимательно ознакомился с темой "тремя темами ниже", но никаким консенсусом там не пахнет, равно как и его "фиксацией". Так что "бессмысленность" моей реплики скорее всего сильно преувеличена :) TenBaseT (обс.) 20:58, 20 ноября 2017 (UTC)
        • Мини-опрос #Принципиальные вопросы по стаб-теме. Вопросы сформулированы так, что для фиксации ответа-консенсуса на них хватило простого арифметического подсчёта: 2/3 есть — ответ положительный. Если такое Вас не устраивает, то проводите 3-й опрос, полноценный, и как было указано Вам выше, подводите «правильный» и обоснованный итог. Только тогда я обвиню Вас в «забалтывании» темы. Лучше хоть что-то сделать, чем бесконечно обсуждать. --VladXe (обс.) 04:15, 21 ноября 2017 (UTC)
          • Данный "Мини-опрос" ничего кроме "неощутимых веяний" определить не может, невозможно междусобойчиком в 8 человек за две недели менять механизм, нормально работающий 12 лет и затрагивающий 400 тысяч статей (400 тысяч статей, КАРЛ!!!!), к тому же "голосовалкой" без обсуждения каких-либо аргументов (вон внизу форума ВП:Ф-ПРА идет спор между MBH, Jeck и NBS можно ли легкий оформительский вопрос решать голосованием, а уж глобальные вопросы точно голосованием не решаются). Это не глобальный консенсус, а именно "междусобойчик", и никто кроме Вас не настаивает на том, что "консенсус зафиксирован". Но если Вы уж так хотите, я могу официально оспорить так называемый "итог". Извольте. TenBaseT (обс.) 08:49, 21 ноября 2017 (UTC)

Анализ шаблонов страна/регион-geo-stub против страна/регион-stub[править код]

По данным из Проект:Незавершённые статьи/Статистика использования провёл сравнительный анализ включений страна/регион-geo-stub versus страна/регион-stub - смотреть здесь Проект:Незавершённые статьи/Статистика использования/geo. Alex Spade 17:05, 12 ноября 2017 (UTC)

Анализ stub-статей о космических объектах[править код]

Решил посмотреть на stub-статьи о космических объектах. Для части из категорий наблюдается некоторая аналогия с Википедия:К удалению/11 июля 2014#Шаблоны и категории для незавершённых календарных статей — когда в таких категория проще обозначить статьи, которые не стабы, поскольку подавляющая часть статей — это ботозаливки по соот.каталогам, и обычный редактор Википедии (не будучи специалистов) просто не может выполнить миссию стабов «Вы можете помочь проекту, дополнив её» - нечем дополнять, кроме как данным из каталога. В особенности это заметно для {{galaxy-stub}}

Stub-шаблон Stub-статей Все статей Доля stub-ов, %
Шаблон:Asteroid-stub 33 2255 1,5
Шаблон:Meteorite-stub 104 1341) 77,6
Шаблон:Galaxy-stub 6556 6642 98,7
Шаблон:Star-stub 748 1920 39,0
Шаблон:Comet-stub 87 174 50,0
Шаблон:TNO-stub 127 174 73,0
Шаблон:Exoplanet-stub 156 353 44,2

1) Большая часть малозначимых/маловесных метеоритов была в своё время совсем удалена

Посему предлагается как минимум отказаться от {{galaxy-stub}}, возможно также от {{TNO-stub}} и {{Meteorite-stub}}. Alex Spade 20:22, 13 ноября 2017 (UTC)

  • Против удаления {{galaxy-stub}}, хотя бы потому, что даже из каталогов можно почерпнуть ещё информацию: какому скоплению/группе принадлежит, с кем взаимодействует. Во многих галактиках фиксируются вспышки сверхновых, небольшая часть попадает в детальное изучение и т. д. Где этого нет, пусть остаётся стаб-шаблон, мы не имеем права лишать читателя информации, что статья неполная. --VladXe (обс.) 21:23, 13 ноября 2017 (UTC)
  • Есть вариант объединить Asteroid-stub и TNO-stub (и, возможно, Comet-stub) в один с описанием «Это заготовка статьи о малом теле Солнечной системы…». --VladXe (обс.) 21:23, 13 ноября 2017 (UTC)

Как мог бы выглядеть унифицированный stub-шаблон, поддерживающий ряд тематик[править код]

Данное предложение является развитием обсуждения #Ограничение номенклатуры stub-шаблонов

Вариант реализации stub-шаблон, поддерживающий ряд (до 3-х) тематик, в чём-то аналогичный по механике Флагификации, мог бы выглядеть вот так -- см. документацию к Шаблон:Stubs. Тематики можно будет указывать в любом регистре (хоть смешанном)(подстроки должны быть/будут только в нижнем регистре). Тематика (если она будет набрана без орфоошибок) будет поддерживать как викилинк на тему, так и соот.категорию. Варианты синонимов для тематики можно будет поддерживать через редиректы.

Главные два НО!

  • 1) Картинка будет единой, даже если задать один параметр. Можно сделать так, чтобы он вытаскивал картинку по первой тематике, но это заметно усложнит все подстроки.
  • 2) 1900+ вариантов подстрок... Но я таки надеюсь (глядя на соот.подтопик), у нас таки их станет намного меньше.

Alex Spade 15:20, 9 ноября 2017 (UTC)

  • А мне не нравится. Чем плох вариант в две-три стаб-записи одна под другой с разными картинками? Не стоит забывать, что при нынешнем уровне образования пиктограммы воспринимаются быстрее, чем слова. --VladXe (обс.) 18:12, 9 ноября 2017 (UTC)
    • А вот чем плох, это см. самое-самое начало темы. Сообщество уже захотело иметь стаб-запись позволяющую объединить стабы в одну строчку. Я лишь выполняю его желание. Alex Spade 18:22, 9 ноября 2017 (UTC)
      • Но не с такой же потерей детализации! --VladXe (обс.) 18:53, 9 ноября 2017 (UTC)
        • //При однострочной реализации// Вы хотите видеть какую-то необщую (первую из трёх) stub-картинку? Или вы хотите видеть все три картинки (последовательно, в одну строку)? Alex Spade 19:03, 9 ноября 2017 (UTC)
          • Наверное второй вариант через небольшой промежуток между пиктограммами. Зато есть плюс — они будут одного размера. --VladXe (обс.) 19:58, 9 ноября 2017 (UTC)
            • Они не будут одного размера, ибо они сейчас не одного размера (точнее ибо они сейчас, как минимум, не в одинаковых пропорциях высоты/ширины). Alex Spade 21:38, 9 ноября 2017 (UTC)
              • Как раз параметр общей высоты шаблона нуждается в унификации, потому что сейчас что отступ до предыдущего текста, что ширина стаб-шаблонов регулируется желанием левой пятки его создателя. --VladXe (обс.) 06:12, 10 ноября 2017 (UTC)
                • К сожалению, у изображений в ВП при их вызове нет параметра высота - так что унифицировать в шаблоне нечего. Т.е. нужно для начала унифицировать пропорции - но это совершенно другая работа - и ею никто не хотел заниматься. Alex Spade 07:13, 10 ноября 2017 (UTC)
                  • Подбор параметра size позволяет регулировать предельную высоту отображения. Предельные габариты пиктограммы должны быть в универсальных требованиях к стаб-шаблонам(-у). --VladXe (обс.) 13:20, 10 ноября 2017 (UTC)
                    • Ручной подбор. Alex Spade 17:02, 10 ноября 2017 (UTC)
                      • Поэтому и предлагаю в общих требованиях к стаб-шаблонам(-у) установить предельные габариты пиктограммы в нём. Тогда переделывать в один будет проще. --VladXe (обс.) 17:15, 10 ноября 2017 (UTC)
                        • Установите, и приведите к нему все имеющие stub-картинки (ручным перебором или написанием специального бота, которых будет считывать параметры файла), тогда и посмотрим. Alex Spade 17:44, 10 ноября 2017 (UTC)
                          • Мне диктаторских полномочий не давали, а до подведения полного итога мини-опроса что-либо конкретное делать не хочу — общественное мнение — величина переменная. --VladXe (обс.) 18:36, 10 ноября 2017 (UTC)
                            • Суть в том, что в предложении нужно учитывать не только собственно предложение, а оценку объёма работ и/или наличие реального (а не гипотетического) участника/группы, которая будет готова его реализовать. Куча идей гибнет именно в силу отсутствия таких участников, особенно в добровольных проектах. Иными словами - не столь важно кто примет решение, важно кто будет его реализовывать. Alex Spade 18:44, 10 ноября 2017 (UTC)
                              • А вот здесь как раз желательно участие инженеров. Во всяком случае результат замены ланг-шаблонов одним бабелем — это тот идеал, который я бы хотел и для этой темы. --VladXe (обс.) 19:32, 10 ноября 2017 (UTC)
                                • Инженеры у нас тоже все добровольные. И шаблоны языков тут совсем не пример, там ситуация был намного проще. Набор ключевых слов (например, ru) и соответствующих им языков (соответственно, русский) был уже готов (стандартизован заранее) и поддерживается на уровне движка. Alex Spade 22:25, 10 ноября 2017 (UTC)
    • Цель ВП — поднимать уровень образования, а не опускаться до. Иначе тем, у кого оный уровень есть, становится некомфортно. И эта категория лиц для нас важнее как потенциальные авторы. Но суть не только в этом, а еще и в техническом усложнении.--Abiyoyo (обс.) 18:24, 9 ноября 2017 (UTC)
      • Что быстрее: идентифицировать картинку или прочитать слово? А опускаться никто не призывает, отключена графика в браузере — читай(те) предложение за пустым квадратиком. --VladXe (обс.) 18:53, 9 ноября 2017 (UTC)
  • Да, ещё забыл - сказать. В данном решении поскольку ключевое слово stub является префиксом, а не постфиксом (stubs/россия против russia-stub) - будет гораздо проще собирать номенклатуру шаблонов и запретить создание новых stub-шаблонов без предварительного обсуждения (дабы она не раздулась заново). Alex Spade 18:33, 9 ноября 2017 (UTC)
    • Конечно, после 5 000-ного включения шаблон смогут редактировать редакторы с флагом не ниже И. --VladXe (обс.) 19:58, 9 ноября 2017 (UTC)
      • Вы не поняли его механику - вся суть не в шаблоне, а в его подстраницах. Если я защищу головной {{stubs}}, то это само по себе не запретит расширение номенклатуры. Но для подстраниц (как страниц с одинаковым префиксом) можно запретить создание новых по маске Шаблон:Stubs\/.+ на MediaWiki:Titleblacklist, не запрещая при этом редактирование имеющихся. Alex Spade 21:36, 9 ноября 2017 (UTC)
        • Как работает ш:rq — имею общее представление. Есть хорошая поговорка: хрен на хрен менять — только время терять. Так что замена 1900 шаблонов на 1900 подстраниц шаблона — эта пустая трата времени. Нужен единый (максимум два) монстрообразный стаб-шаблон с операндом выбора внутри, внутри которого и происходит формирование отображаемой строки. --VladXe (обс.) 06:12, 10 ноября 2017 (UTC)
          • Предлагаемый шаблон единый, как осуществляться в нём выбор - это технический фича, подстраницы работают намного быстрее, чем "предлагаемый" вами (и уже рассмотренный ранее) switch (а то и 2-3). Так что он уже далеко нет тот же хрен. И опять же в новом решении мы сможем запретить расширение номенклатуры на уровне движка, чего в текущем варианте не сможем. И мы сможем поддерживать однострочный режим, чего в текущем варианте не можем. Если, вдруг, однострочный режим будет таки отброшен, это лишь упростит шаблон, но такая полезная фишка как автозапрет расширения номенклатуры без ведома сообщества останется. Alex Spade 07:11, 10 ноября 2017 (UTC)
            • Не согласен с Вами — при 5000+ включений (а статей-стабов гораздо больше) включается механизм защиты шаблонов до флага инженера, а инженеры, администраторы и бюрократы — люди, которым викиобщество доверяет, так что защита от «расширения номенклатуры без ведома сообщества» организована. --VladXe (обс.) 13:13, 10 ноября 2017 (UTC)
              • Вы не несогласны, вы лишь не понимаете, как работает предлагаемый {{stubs}}. Если защитить головной шаблон, это не помешает добавить к нему тема-строки. Точно также как и защита {{stub-meta}} не мешает развитию номенклатуры. Но в отличии от действующего варианта, в предлагаемом варианте номенклатуру можно будет защитить другим способом. P.S. Ещё раз уточню - swicth-шаблон для текущей номеклатуры (или даже сокращённой в три раза), позволяющий защитить всё одним махом, никто делать не будет, ибо он может заметно замедлить работу ру-ВП. Alex Spade 16:58, 10 ноября 2017 (UTC)
                • (КР) А если будет единый стаб-шаблон без подшаблонов, то никакой дополнительной защиты не надо организовывать, всё уже сделано до нас. Тогда не вижу смысла затевать столь кардинальную реформу, проще только ограничить номенклатуру и создать место для её регулирования. --VladXe (обс.) 17:16, 10 ноября 2017 (UTC)
                  • Когда вы сможете сократить номенклатуру ну хотя бы до порядка 100 единиц (считая вместе с алиасами), тогда и посмотрим (ибо даже в этом случае будет до 300 переключений, если нужно будет сохранить и тему, и категорию, и картинку - что уже в 4 раза больше, чем единичный rq, а ведь stub-meta ещё и гораздо чаще используется, чем {{rq|topic}} - 400к+ против 90к+). Ну, и, заодно, отмените предыдущее желание сообщества об необходимости поддержки однострочного режима для объединения тем (ибо каждая доп.тема пропорционально увеличит время работы switch-а). Alex Spade 17:47, 10 ноября 2017 (UTC)
  • Ещё один минус этого варианта — отсутствие надписи, декларирующей, что стаб-шаблон желательно уточнить. Вероятен вариант, когда в стабе описывается учёный и самая главная его теория/открытие, при этом редактор, не заморачиваясь, проставил параметры персона и наука в общем стаб-шаблоне. В действующей версии в обоих шаблонах предложат уточнить стаб, а в универсальной такого предложения нет. --VladXe (обс.) 08:59, 11 ноября 2017 (UTC)
    • Это не недостаток. Допилить в предлагаемый шаблон можно хоть все семь (если считать texticon) параметров из действующего {{stub-meta}}, создав соответственно template:stubs/имя_параметра/имя_темы (по аналогии с template:stubs/тема/имя_темы - например, template:stubs/тема/россия) и подключив отработку параметра в шаблон (только что придётся вставлять ifexist-проверку, которую ещё нужно будет проверить на быстроту отработки). В том время, как в желаемом общем шаблоне на switch-ах, каждый доп.параметр будет приводить к ещё одному switch-у. Так что тут главное определиться, что допиливать из stub-meta - в предыдущем обсуждении уже даже эмуляция двух-трёх ключевых параметров (article, category, и возможно image) вызывала «ужас и трепет». В предлагаемом шаблоне хотя бы уже удалось «объединить» article и category без потери их функциональности. Можно аналогично объединить ещё image, texticon и alt - в template:stubs/пиктограмма/имя_тема. Но specification точно придётся обрабатывать отдельно (и ещё разбираться с конфликтом, если нужно уточнять обе или все три темы). Alex Spade 09:43, 11 ноября 2017 (UTC)
      • Я не настолько разбираюсь в викиразметке, чтобы создавать шаблоны, но в программировании чуть-чуть смыслю. Достаточно одного оператора выбора по параметру article, в котором либо из подшаблонов, либо из тела оператора передаются хоть все 7 параметров {{stub-meta}} + ещё один параметр — флаг, определяющий, должна ли выводится строка с просьбой уточнить стаб-шаблон. То, что Вы назвали конфликтом, легко убирается одной функцией (ИЛИ, хотя можно и И) по этому флагу. --VladXe (обс.) 10:07, 11 ноября 2017 (UTC)
        • В том и дело, что язык викиразметки не язык программирования, то что несложно сделать в большинстве языков программирования, в языке викиразметки может не работать и приходится эмулировать желаемое иными способами-ухищрениями. Поэтому для данной многопараметрической задачи, там где в языке программирования действительно понадобится 1 switch на группу параметров, в языке викиразметки понадобится N switch-ей (где N - количество параметров). Гитотетически, если/когда будет жёстко установлена и крайне существенно сокращена номенклатура stub-шаблонов, тогда можно будет написать/переписать код на Lua (сейчас возможный словарь параметров и значений просто офи-фигительный, что катастрофически сказывается на быстродействии) - но именно, если/когда. Предложенный шаблон (как оболочка) может работать уже сейчас, нужно лишь создать словарь - который нужно создавать в любом случае.
          Конфликт в том, что для эмуляции stub-meta нужно вывести не просто универсальную надпись "Это примечание по возможности следует заменить более точным" (как в {{stub}}), а предложить частную страницу/категорию (как в {{geo-stub}}), т.е. - что выводить если обе (или все три) темы требуют своего частного уточнения? Alex Spade 10:53, 11 ноября 2017 (UTC)
          • Вот здесь как раз придётся пожертвовать точностью ради самого факта, что стаб-шаблон (или одну из представленных в списке частей) следует уточнить, оставив только универсальное примечание Ш:stub. А примечание должно быть — это следует из согласованной части П:КАТ-ВС. --VladXe (обс.) 09:53, 12 ноября 2017 (UTC)
  • Кстати, вопрос на засыпку - капитализация в параметрах в примерах имеет какой-то смысл? Тогда его надо бы в документации отразить. Фил Вечеровский (обс.) 10:34, 11 ноября 2017 (UTC)
    • Это лишь демонстрация того, что (см. начало топика) «тематики можно будет указывать в любом регистре (хоть смешанном)»: россия, Россия, РОССИЯ, и т.д. Если шаблон будет таки выбран за базу, естественно в его документации не будет такого БезОбразиЯ. Alex Spade 10:53, 11 ноября 2017 (UTC)
  • Обнаружил шаблон {{Болванка}} — универсальный стаб-шаблон для одной темы. --VladXe (обс.) 10:57, 12 ноября 2017 (UTC)
    • Если вы посмотрите его код, вы увидите, что это не самостоятельный шаблон (как {{rq}} или {{stubs}}), а двойной-switch-обёртка над существующей номенклатурой шаблонов на базе {{stub-meta}} - т.е. он заведомо будет работать медленнее, и хорошо, что у него пока немного включений. И однозначно не будет работать без {{stub-meta}}. И он пока не универсальный - вариантов stub-шаблонов намного больше. Кроме того, а) автор решил не сообщать AWB-разработчикам о его существовании, б) при ошибочном введении параметров он ничего не выдаёт. Попробуйте, например, {{Болванка|Футболист|Ярославская область}}. Alex Spade 13:46, 12 ноября 2017 (UTC)

Другой Flow[править код]

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Пока Flow ограничен тестовыми страницами, в рамках 2017 Wishlist можно было бы запросить локально отличающийся flow. Обычным способом (через фабрикатор) пожелание могут отказаться делать. Есть ли какие-то системы дискуссий, которые по вашему мнению можно было бы реализовать в вики через flow или как-то изменить flow чтобы его было удобно использовать для привычных дискуссий? --Sunpriat (обс.) 21:23, 8 ноября 2017 (UTC)

  • Если я правильно понял вопрос, идеальная система в Живом Журнале. Именно ее мы пытаемся имитировать нашими отступами, это точно та же логика, только там она реализована автоматически. Добавить к ней вики-парсер - это всё, что нужно. Vcohen (обс.) 21:30, 8 ноября 2017 (UTC)
    • Как там выглядят очень длинные лесенки? --Sunpriat (обс.) 21:53, 8 ноября 2017 (UTC)
      • В ЖЖ длинные лесенки автоматически сворачиваются, показывается несколько начальных комментов и надпись в духе "читать ещё X комментов". Похожая система есть на YouTube, но, имхо, она менее удобнее для нас - ибо виден только первый коммент в лесенке, остальные нужно раскрыть, и последующие комменты идут не в лесенку, а по левому краю. Наиболее похожая на нас система на мой взгляд на habrahabr.ru - но именно наиболее похожая (а вот насколько удобная...). Alex Spade 22:30, 8 ноября 2017 (UTC)
        • Нашёл большую тему https://tema.livejournal.com/2630714.html - кроме срезания ветки на определённом уровне в "ещё X комментов" при браузере в половину ширины экрана комментарии стоят друг под другом. Теряется логичность ветвления, которую хотели иметь. Друг под другом они показываются и на мобильных. В вики большое количество посетителей с узких мобильных устройств. --Sunpriat (обс.) 08:20, 9 ноября 2017 (UTC)
          • У того же Темы есть занятная надстройка для ЖЖ, которую он используется для своих фуршетов (публичных дискуссий), она на мой взгляд достаточно адекватно демонстрирует то, как сделать дискуссии в ЖЖ хорошо читаемыми. См, пример. В этой надстройке нет непосредственно формы отправления комментариев, они идут через само ЖЖ, но если её добавить, то что-то подобное мне кажется, можно было бы реализовать и здесь. На первый взгляд она кажется покрывает все основные ожидания википедистов. Rampion (обс.) 08:40, 9 ноября 2017 (UTC)
        • На Хабре да, вполне удобная система комментов для длинных дискуссий. Вот пост на >1к комментариев для наглядности. Похожая и по сути и внешнему виду система комментов еще на vc.ru. Rampion (обс.) 08:48, 9 ноября 2017 (UTC)
          • А я бы привёл в пример Пикабу. Очень похоже на хаброкоммментарии, но со сворачиванием длинных веток и возможность раскрыть сразу всю ветку, как в ЖЖ (причём, в настройках можно выбрать глубину, при превышении которой ветка сворачивается). А в мобильном приложении есть очень крутая фишка: при нажатии на фразу "ответ на комментарий" появляется родительский комментарий, что здорово облегчает ориентирование среди кучи под-веток. 109.172.98.69 16:10, 9 ноября 2017 (UTC)
          • На хабре 15 уровней (на vc - 5) после них стенка. В обычном - лесенка, в мобильном лесенка другая - отспуп у подветки между двумя ветками. Т.е. и жж и хабр на определённом уровне (жж от ширины экрана, хабр 15 уровней) сливают в ту же плоскость без разбора ветка дальше или подветка. --Sunpriat (обс.) 21:24, 9 ноября 2017 (UTC)
  • Не нужен другой флоу, система отступов флоу очень хороша и продумана, хотя и слегка непривычна (чего нельзя сказать о Хабре, Друпале и ЖЖ) —be-nt-all (обс.) 18:11, 10 ноября 2017 (UTC)
    • Минимум три клика (это если не было конфликта редактирования) для написания комментария вместо привычного в веб-проектах одного, да еще и дополнительное время для вставки подписи – это хорошо и продумано? Серьёзно? Нет, я не оправдываю флоу, он плох в его текущем виде, но текущая система общения в Википедии – это какой-то плод работы инопланетных осьминогов, а не людей, которые хорошо умеют в UX/UI. Я не хочу обидеть тех людей, которые все это когда-то придумали, они молодцы, проделали колоссальный труд, просто на юзабилити подзабили, к сожалению. Сириусли, диалогов более неудобных чем в Википедии, я еще нигде не встречал. Я то с этим мирюсь, ибо уже привык за многие годы, но говорить о том, что это хорошо и продумано? С этим я вообще не согласен. Rampion. 16:41, 11 ноября 2017 (UTC)
      • Не один и три, а два и два - в обоих случаях нужно сначала нажать кнопку, выводящую поле для написания коммента, а затем - кнопку сохранения. Люди ничего не придумывали, они просто сделали универсальный редактор и использовали его везде - и в статьях, и в обсуждениях. Идея получилась очень удачной и плодотворной, например, боты могут редактировать оба типа страниц одним и тем же образом. MBH 17:15, 11 ноября 2017 (UTC)
        Все таки один и три. В куче сервисов форма отправки комментария открыто по умолчанию, достаточно лишь написать текст и нажать enter. В Википедии же сейчас нужно кликнуть на "Править", найти нужное место в полотне текста, кликнуть туда, где ты хочешь ответить, затем кликнуть на "записать страницу. Т.е. трата времени на поиск нужного места для написания, трата времени на вставку подписи и еще трата времени на два лишних клика. Насчет ботов - здорово что ботам удобно, жаль только большинство статей в русской Википедии и правок в её обсуждениях сделана не ботами, а людьми. Rampion. 18:38, 11 ноября 2017 (UTC)
      • "Хороша и продумана" было сказано про флоу, а не про нынешнюю систему. Vcohen (обс.) 17:20, 11 ноября 2017 (UTC)
      • (КР)@Rampion:. Вы меня не поняли. Я всеми четырьмя конечностями (+) за Флоу (только проблему отката как-то решить надо), я (−) категорически против другого Флоу, то есть приведения продуманной системы отступов Флоу к устаревшему «стандарту» друпала (примеры которого мы можем видеть в ЖЖ и на хабре). То что сейчас, с конфликтами редактирования и разнобоем отступов — в общем, слов в рамках ВП:ЭП у меня нет —be-nt-all (обс.) 17:22, 11 ноября 2017 (UTC)
        Моя вина, да, сперва совсем неправильно прочел и понял вашу мысль, прошу прощения. Rampion. 18:38, 11 ноября 2017 (UTC)
    • Система отступов Flow хороша, но продумана не до конца. В прошлом году я предлагал решение проблемы с порядком ответов, но судя по всему в текущем варианте логики работы Flow реализовать эти варианты будет сложно.--Tucvbif???
      *
      14:35, 13 ноября 2017 (UTC)
  • Сформулировал так meta:2017 Community Wishlist Survey/Miscellaneous#Multilevel Flow. Кстати, предлагают и meta:2017 Community Wishlist Survey/Editing#Release VE on Talk pages. Там можно комментировать. --Sunpriat (обс.) 17:41, 11 ноября 2017 (UTC)
  • Как мне кажется, проблема Flow не в отображении дискуссий, а в их хранении. Я так понял, что сейчас хранится порядок сообщений и величина отступа. Если бы они хранились по-нормальному, не было бы проблем отображать их в том стиле, в котором удобнее читателю: хочешь — будет flow, хочешь — как в ЖЖ, хочешь — вообще плоский форум со ссылками, как в имиджбордах.P.S. А можно где-то посмотреть исходники flow?нашёл, очевидно же.--Tucvbif???
    *
    21:32, 11 ноября 2017 (UTC)
    • Надо будет почитать исходники, но если всё, как вы говорите, это будет совсем другой flow. Изменение архитектуры, сравнимое с переходом от Liquid Threads к Flow. Оно, конечно и не плохо, хотя рендеринг обсуждений —> нагрузку на сервера несколько утяжелит. —be-nt-all (обс.) 23:54, 11 ноября 2017 (UTC)
      • Как мне кажется, если и утяжелит, то совсем чуть-чуть. Но текущая схема хранения — это тупиковый путь.--Tucvbif???
        *
        06:23, 12 ноября 2017 (UTC)
  • У меня простой вопрос — новый Флоу будет реализован как абстракция над традиционной вики-разметкой (с возможностью ее править по-старинке по аналогии с визредом) или опять будет ее заменять?--Abiyoyo (обс.) 00:29, 12 ноября 2017 (UTC)
    • По-старинке не получится - Флоу принципиально хранит/правит каждое сообщение отдельно. Идеи о сплошном редактировании визредом (надстройки над ним) можно комментировать в meta:2017 Community Wishlist Survey/Editing#Release VE on Talk pages пока не началась стадия голосования. --Sunpriat (обс.) 01:27, 12 ноября 2017 (UTC)
      • Ясно, спасибо. Думаю, в этом случае его не поддержат тут. Многие привыкли редактировать код, визуальные штуки многим не нравятся.--Abiyoyo (обс.) 01:36, 12 ноября 2017 (UTC)
        • «Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь». Вы же не редактируете статьи через SQL-запросы? Tucvbif???
          *
          06:23, 12 ноября 2017 (UTC)
          • Ну да. Быструю, послушную, не пугливую, питающуюся жидкой пищей и не дающую мочи и навоза. И ещё, если можно, встроенную в экипаж. Что-то мне это напоминает :-) Фил Вечеровский (обс.) 12:18, 12 ноября 2017 (UTC)
          • Через SQl — нет, так как доступа к базе нет. Через api.php — да, см. AbiyoyoBot. Меня лично интересует, насколько новый механизм гибок. Визуальные штуки — хорошо, но часто лишают гибкости. Не хотелось бы ее потерять, хотелось бы сохранить доступ к нижнему слою, не хотелось бы чтобы меня ограничивали узким набором действий, встроенных в UI, лишая доступа к базовому уровню данных (хотя бы на уровне кода страницы).--Abiyoyo (обс.) 12:47, 12 ноября 2017 (UTC)
            • В модели Flow (или другого форумного движка) отдельную реплику можно считать как отдельную страницу. То есть «нижний слой» — это SQL-таблицы. Какие-либо действия с логикой ответов — это уже новая сущность, которую всё равно нужно будет надстраивать над движком. Поэтому лучше заранее обдумать, какие именно действия над «нижним слоем» могут понадобиться.--Tucvbif???
              *
              13:12, 12 ноября 2017 (UTC)
              • Какие именно действия? Ну, для начала возможность скопировать в обсуждение код из статьи, обсудить его, исправить, а потом скопировать обратно в статью. Vcohen (обс.) 13:37, 12 ноября 2017 (UTC)
              • В том и проблема, что между sql и представлением ничего нет. Вики-разметка дает ощущение свободы, вся суть в том, что я не должен продумывать зараенее четко очерченный функционал. А модель Флоу подразумевает, что разрабы продумали заранее набор допустимых действий, реализовали их, и больше у меня свободы нет. Новичкам Флоу м.б. проще, зато теряется все очарование вики как места, где можно изобретать, строить самому свое окружение. Ясно, что Фонд спытается сейчас привлечь новичков «простым» интерфейсом, но это убьет всю идеологию вики с ее ощущением свободной песочницы.--Abiyoyo (обс.) 13:45, 12 ноября 2017 (UTC)
                • А зачем что-то изобретать в обсуждениях? В статьях - понятно, различные виды навигации, оформления, я и сам всё это люблю. А с обсуждениями просто: А пишет реплику, Я отвечаю на его реплику, он отвечает на мою и т.д. Какие-то действия над структурой ответов производить добросовестному участнику смысла нет. Разве что закрыть ветку обсуждения, либо вынести её в отдельную тему - но такое нужно очень редко.--Tucvbif???
                  *
                  15:25, 12 ноября 2017 (UTC)
                  • Мне кажется, что тот факт, что я, например, не редактирую вашу реплику, хотя имею к тому техническую возможность, создает какое-то базовое ощущение совместности. Это не вопрос «зачем», это скорее есть основание специфического вики-взаимодействия. Хотя где-то, например, могу (поправить число звездочек, если бы вы ошиблись). То есть тут такие тонкие социальные механизмы работают. Флоу это все убивает, а именно ограничивает технически то, что сейчас держится на уровне социального взаимодействия. И я думаю, подспудно неприятие Флоу связано именно с тем, что он приведет к большему разобщению участников, к росту отчуждения.--Abiyoyo (обс.) 15:56, 12 ноября 2017 (UTC)
                    • Это — просто боязнь перемен. Я лично во всех этих поправлелиях звёздочек и напоминаниях, что надо ставить подпись, вижу что-то из той же области, что и звонки родителей взрослому ребёнку, не забывает ли он надевать шапку.--Tucvbif???
                      *
                      22:24, 12 ноября 2017 (UTC)
                    • Во Флоу, если что, править чужие реплики можно. — Джек (обс.) 15:00, 13 ноября 2017 (UTC)
                      • У нас можно, потому что это я продавил такую возможность для всех юзеров, когда у нас тестово включали флоу. По умолчанию и в других разделах манипулировать чужими репликами во флоу могут только админы. MBH 15:04, 13 ноября 2017 (UTC)
                        • Не знаю, как было раньше, но сейчас везде можно. — Джек (обс.) 15:15, 13 ноября 2017 (UTC)
                        • А зачем править чужие сообщения? Посмотреть исходный код — хорошо, но редактировать с возможностью сохранения — не нужно. Администраторов при этом нужно наделить модераторской функцией удаления (сокрытия текста) сообщений. — smigles 20:08, 13 ноября 2017 (UTC)
                          • Ботозамена шаблонов, некорректного кода, заменённых картинок и т.д., всякие технические работы - как самый минимум. Немедленное сокрытие разглашённых ЛД до прихода администратора - другой пример. Нельзя отказываться от хорошо себя зарекомендовавшего принципа, что любой может править реплики любого. MBH 23:11, 13 ноября 2017 (UTC)
                            • Хорошо. Представим, что боты умеют работать с «Флоу». Выдаём им права на редактирование. Возможно, ещё выдаём инженерам. Но выдавать всем и вся, даже анонимному школьнику Пете, который придёт повандалить на какую-нибудь непопулярную страницу, где его правка может не быть отменена долгое время, — это слишком. А разглашение личных данных — это один на миллион. — smigles 00:16, 14 ноября 2017 (UTC)
                              • Если школьник Петя может править статьи (!), причем это основополагающий принцип Википедии, - зачем защищать от него обсуждения? Vcohen (обс.) 08:31, 14 ноября 2017 (UTC)
                                • Школьник Петя имеет право править написанные мною статьи (если он действует в рамках правил), но не имеет права править мои реплики в обсуждениях. LeoKand 09:11, 14 ноября 2017 (UTC)
                                  • Буквально тремя строчками выше перечислены случаи, когда нужно, чтобы он имел право. Вы берете случай, когда реплику написали лично Вы, а правит ее очевидный вандал, - но этот случай невозможно распознать автоматически, в общем случае писал реплику кто угодно и правит кто угодно. Vcohen (обс.) 09:26, 14 ноября 2017 (UTC)
                                    • В случае разглашения личных данных достаточно лишь разрешать скрывать сообщение. Других случаев, когда постороннему человеку нужно исправить чужую реплику так и не показано.--Tucvbif???
                                      *
                                      11:04, 14 ноября 2017 (UTC)
                                      • Другой случай: на СО совместно несколькими участниками правится некий викикод, предназначенный в конечном счете для переноса в статью. Первый раз его приносит один участник и размещает в своей реплике. А дальше? Vcohen (обс.) 11:12, 14 ноября 2017 (UTC)
                                        • Пример надуманный, даже сейчас в таких случаях обычно размещают код в песочнице.--Tucvbif???
                                          *
                                          12:05, 14 ноября 2017 (UTC)
                                          • Первый раз слышу, чтобы песочницу правили несколько человек в процессе обсуждения. Вот свежий пример - проект добавки в правила: один написал версию прямо в обсуждении, другие ее правят. Vcohen (обс.) 12:37, 14 ноября 2017 (UTC)
                                            • Разработчикам нужно найти золотую середину: не отказываться от новой системы, но и не урезать текущие возможности. Например, к каждой теме добавлять поле, которое может редактировать каждый и где не ставятся подписи. Если оставить редактирование полностью свободным во «Флоу», то получится, что один участник будет вносить свои правки от имени другого (того, чья подпись стоит). — smigles 13:15, 14 ноября 2017 (UTC)
                                              • Такие мелочи можно до бесконечности придумывать, и на выходе получим то же, что получилось с Flow — неработоспособный продукт, в котором не могут устранить критические недостатки, зато постоянно прикручивают новые свистоперделки. Для начала нужно составить список критической функциональности, без которой обсуждения вести невозможно, а когда будет готов минимально работоспособный продукт — думать, как прикрутить к нему голосовалки, итогоподводилки и прочие красивости.--Tucvbif???
                                                *
                                                13:40, 14 ноября 2017 (UTC)
  • Может, уже пора отправлять в ВП:ВЕЧНО? Ну не вижу я перспектив поменять тут консенсус, тем более, что не удаётся даже договориться о том, какая логика должна быть у обсуждалки. AndyVolykhov 14:41, 13 ноября 2017 (UTC)
  • Извиняюсь за резкие слова, но сколько уже можно мусолить тему?! Flow в принципе не пригоден для повседневного использования в Википедии! Не буду в 100500 раз повторять одни и те же аргументы. Желающие могут их увидеть в многочисленных архивах — например здесь или здесь. А самых отважных приглашаю в песочницу Flow — так как за ней никто не следит, она уже капитально отвандалена. Попробуйте вернуть её в состояние, бывшее год назад. В обычном обсуждении для этого достаточно нескольких щелчков мыши. А во Flow? -- Q-bit array (обс.) 21:43, 20 ноября 2017 (UTC)
    • Система отступов в прошлом уже менялась, + в планах тогда закладывались некие другие режимы флоу. Вопрос в том, можно ли сформулировать для разработчиков "что бы хотели вместо текущего", это другая тема, не обсуждение текущей версии флоу. --Sunpriat (обс.) 23:25, 20 ноября 2017 (UTC)
      • Изъяны системной архитектуры Flow делают его использование в качестве замены обсуждений Википедии в принципе невозможным. И проблема в том, что это не исправить «малой кровью», так здесь не пара багов в коде (которые можно быстро исправить), не пара отсутствующих фич (которые можно прикрутить), а была выбрана в принципе неправильная системная архитектура (каждая реплика сама по себе). Единственное решение проблемы — полная разработка новой системы с нуля. Также хочу пояснить, что я не консерватор и тоже был бы рад улучшенному движку обсуждений. Просто Flow в принципе не подходит, как его не крути. Как видно из многочисленных прошлых обсуждений, я провёл достаточно много времени, тестируя Flow и теперь могу подкрепить моё мнение твёрдыми фактами. :-) -- Q-bit array (обс.) 09:35, 21 ноября 2017 (UTC)
        • Архитектура «каждая реплика сама по себе» — единственно возможная архитектура для более-менее структурированных обсуждений. Чтобы хорошо структурировать ту наскальную живопись, с помощью которой общение в ВП происходит сегодня, нужен сильный ИИ, и то не факт, что он справится. То, что некоторым администраторам ВП привычно откатывать обсуждения к дате, не думая — не преимущество текущей системы. То, что в заброшенном год назад обсуждении порезвились «вандалы» и администратор не знает как его почистить — не недостаток системы обсуждения. Или кто-либо из нынешних администраторов смог бы вернуть к жизни какой-нибудь заброшенный вандализированный вики-сайт, не имея бекапов?--Tucvbif???
          *
          11:20, 21 ноября 2017 (UTC)
          • Здесь я совершенно не согласен. Архитектура «каждая реплика сама по себе» применима только к очень простым обсуждениям, типа срачей в комментариях к видео в ютьюбе. Технически вполне возможно создать форумный движок позволяющий обрабатывать все реплики как единое целое со всеми комфортабельными и необходимыми функциями типа просмотра диффов изменений, отката к прошлой версии и т. п. Даже такой тривиальный вариант, как специальный визуальный редактор для обсуждений, базирующийся на нынешнем Викидвижке будет работать намного лучше Flow — особенно если технически ограничить ручное редактирование исходного текста обсуждения (тогда никто не сможет сломать викитекст в ручную). Насчёт абстрактных заброшенных и отвандаленных вики-сайтов могу только сказать, что если у вандалов не было расширенных прав (типа права удаления и объединения правок), то убрать массовый вандализм можно очень быстро. Невероятно, но факт! В этом и заключается одна из сильных сторон Вики-движка: убрать вандализм значительно легче, чем отвандалить. А в Flow всё с точностью наоборот. Лёгкий вандализм требует значительной затраты усилий для его устранения, а сильный вандализм практически неустраним. -- Q-bit array (обс.) 12:13, 21 ноября 2017 (UTC)
            • Технически можно навесить возможность отката и просмотра диффов над группой отдельных страниц, и это будет технически проще, чем распарсивание дискуссии с одной викистраницы, не говоря уже о ситуациях, когда нужно отменить правки в конкретной ветке, не мешая активному обсуждению в другой.--Tucvbif???
              *
              12:20, 21 ноября 2017 (UTC)
            • И про «простые обсуждения, типа срачей в комментариях к видео в ютьюбе» не надо. ВП — не единственное место, где ведутся серьёзные разветвлённые дискуссии. Зайдите на Хабр, зайдите во многие журналы в топе ЖЖ. Да даже на имиджбордах, несмотря на отсутствие отступов, вести сложные структурированные дискуссии более удобно, чем в ВП.--Tucvbif???
              *
              12:35, 21 ноября 2017 (UTC)
        • "Изъяны", "неправильная" - общие слова, с конкретным было бы понятней; предложение meta:2017 Community Wishlist Survey/Archive/Who to whom in the Flow закрыли, с комментарием, что реплики будут связанными - это решает проблему? Где-нибудь есть более правильная, по вашему мнению, система? "Единственное" - нет ресурсов. LQT был заброшен. Есть команда, работающая над многими проектами; они хотели бы работать над флоу, ей выделяется время на флоу; сообщество может с ними общаться, влиять на решения и приоритеты. Конечно можно стоять в сторонке от текущей версии, ждать новое "с нуля", но не дело запрещать обсуждать/"мусолить" изменения. "подкрепить фактами" - вместо этого хотелось бы увидеть "и всё выло высказано разботчикам, созданы запросы". Если что-то осталось, могу помочь довести до разработчиков, оформить на фабрикатор. --Sunpriat (обс.) 12:05, 21 ноября 2017 (UTC)
          • Увы, это не первое и даже не десятое обмусоливание, пардон, обсуждение Flow. Уже столько раз тратил время на составление списка технических требований… Теперь мне просто надоело копипастить одни и те же аргументы в каждое новое обсуждение, с завидным постоянством всплывающее раз в несколько месяцев. Моя первая реплика здесь содержала ссылку на аргументы, высказанные в предыдущем обсуждении, а там — ссылки на предыдущее и так далее. -- Q-bit array (обс.) 13:13, 21 ноября 2017 (UTC)
            • А почему бы не вывесить требования где-нибудь в общедоступном месте для обсуждения? Вместо того, чтобы переходить по ссылке на предыдущее обсуждение, в которой искать ссылку на пред-предыдущее, не лучше ли было бы иметь некое резюме, чтобы прочитать ваши аргументы напрямую?--Tucvbif???
              *
              13:22, 21 ноября 2017 (UTC)
              • Хорошо, скопипащу свои аргументы ещё раз. :-) Проблема в том, что и на этот раз они уйдут в архив вместе с их обсуждением. А в следующем обсуждении через несколько месяцев история повторится. Выявленные недостатки Flow являются системными (о чём я уже писал в этой итерации обсуждения), устранить их можно только разработкой новой системы с нуля. -- Q-bit array (обс.) 13:39, 21 ноября 2017 (UTC)
  • Возможно, нубский вопрос, но я вот чего не понимаю: а почему нельзя сделать эмуляцию форумного движка внутри вики? Весь текст заворачивается в шаблоны, эти же шаблоны полностью подменяют ссылки на правки секций и т. п., а правки, нарушающие структуру шаблонов, отклоняются фильтром. И там внутри шаблонов — что хотите, лесенки, сворачивание, расцветка. Можно сделать оформление кастомизируемым. AndyVolykhov 11:37, 21 ноября 2017 (UTC)
    • От системы обсуждения требуется не цвета и лесенки, а:
      1. Простой постинг с автоматической подписью. Если для ответа на сообщение нужно будет вписать кучу лишнего викикода — нафиг такую систему;
      2. Возможность следить за отдельными темами (сейчас такая возможность появилась, но всё же сделано довольно криво: нужно в ЛП вставить шаблон, в шаблон вставить ссылку на обсуждение, потом вручную нажимать на обновление), а в идеале — за отдельными ветками обсуждения;
      3. Возможность узнать, на какое конкретно сообщение был дан ответ, лучше в виде ссылки на якорь ответа;
      4. Возможность архивации (желательно — автоматической) без потери ссылки на сообщения;
      5. Возможность запостить сообщение без конфликта редактирования;
      6. Возможности модерации: сокрытие сообщений, запрет постинга в отдельные ветки или отдельным участникам и т.д.
    • Сомневаюсь, что всё это в принципе можно реализовать поверх существующего движка.--Tucvbif???
      *
      12:03, 21 ноября 2017 (UTC)
      • Честно говоря, не вижу ничего нереализуемого во всём этом. Может, разве что прикрутить какой дополнительный обработчик конфликтов. Или все сообщения писать в конец после существующих (как классический форумный топик), а потом уже шаблонами отображать это всё как лесенку, показывая, на что был ответ (шаблон должен будет подхватить ссылку на исходное сообщение, если к нему было нажато «ответить»). AndyVolykhov 13:57, 21 ноября 2017 (UTC)
        • Я вот не представляю, как в рамках существующей системы организовать п4? Пункты 2,3, конечно, сделать можно, но для этого каждое сообщение нужно оборачивать довольно большим кол-вом кода. А если ещё навесить шаблон, который будет строить из этого лесенку, получится реально монстр.--Tucvbif???
          *
          14:05, 21 ноября 2017 (UTC)
  • Голосование 2017 Wishlist началось, но оба предложения отклонили. Спасибо всем прокомментировавшим, дальше отвлекать всех нет смысла. --Sunpriat (обс.) 19:06, 27 ноября 2017 (UTC)

Принципиальные вопросы по стаб-теме[править код]

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.
Данное обсуждение является развитием обсуждения #Ограничение номенклатуры stub-шаблонов

Обсуждать можно долго, но нет самого главного — мандата на действие. Просьба к участникам ответить на следующие утверждения, особенно на первый.
Я не против если этот подраздел преобразуют в опрос, но следующие 4 суток я оффлайн. А вообще ВП:ПС. --VladXe (обс.) 22:35, 6 ноября 2017 (UTC)

Следует упорядочить и сократить количество стаб-шаблонов[править код]

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

  1. В целом имеется намечается консенсус, что необходимо как упорядочить и сократить количество стаб-шаблонов.
  2. Имеются К настоящему времени предложены три основных подхода к оптимизации. А) Через порог минимального использования. Б) Через порог на максимум общего числа stub-шаблонов. В) Через мнение проектов.
  3. Наиболее простым направлением оптимизации, видимо, можно считать обсуждение необходимости малоиспользуемых шаблонов. Вместе с тем, на первом этапе, видимо, не стоит избавляться от stub-шаблонов, у которых есть более популярные подварианты (например, {{ballet-stub}} и соответственно {{ballet-bio-stub}}).
  4. Самым минимальным порогом при обсуждении пока было названо число включений равное 5 (включений в статьях), однако этот порог пока не получил аргументации и/или поддержки. Следующим наиболее частым порогом пока стало число включений в районе 20-30 (или ~600-750 шаблонов из 1900+). И в обсуждении пока не фигурировали предложения о пороге выше 100.
  5. Дабы двигаться постепенно, одновременно нащупывая более точную позицию сообщества, малоиспользуемые stub-шаблоны (до 20-30 включений) (если не поступит заметных противопоказаний по ходу данного обсуждения или на КУ) будут постепенно выдвигаться к удалению через КУ с информированием по-возможности соответствующих проектов.

Alex Spade 17:35, 10 ноября 2017 (UTC)

  • Из предложенного выше обсуждения следует только п. 1. Остальное надо детально обсудить в новом подрзделе. --VladXe (обс.) 17:52, 10 ноября 2017 (UTC)
    • Вы полагаете нужно даже обсуждать границу 5? Alex Spade 18:01, 10 ноября 2017 (UTC)
      • Да, на подстраницах КУ. Или Вам выдали полномочия диктатора Википедии? --VladXe (обс.) 18:15, 10 ноября 2017 (UTC)
        • Странно, вообще в сим итоге и написано, что малоиспользуемые шаблоны пойдут на КУ. Тогда в чём проблема? Alex Spade 18:36, 10 ноября 2017 (UTC)
          • Таки мне не нравится, что конкретный ответ размазали на алгоритм из 5 действий, ни коим образом в этом ответе не упомянутых. И что рано подвели итог — минимальный срок любого варианта опроса — неделя. --VladXe (обс.) 18:40, 10 ноября 2017 (UTC)
          • Если я не ошибаюсь, с юридической т. з. первое называется подлогом. --VladXe (обс.) 18:42, 10 ноября 2017 (UTC)
            • Не вопрос, назовём сиё промежуточный частный итог. Прекращение обсуждения не планировалось, но на более конкретных вариантах будет проще понять мнение сообщества. У вас есть возражения против выдвижения первых партий малоиспользуемых stub-шаблонов (начиная с самых малоиспользуемых, исключительно до 5 включений, не более 5 в день) на тестовое обсуждения на КУ? Alex Spade 18:59, 10 ноября 2017 (UTC)
              • Возражений нет, скорее есть просьбы — при удалении указывать шаблон-приемник, который должен заменить удаляемый (если такое вообще возможно), и при «удалительном» итоге не забывать корректировать соотв. списки стаб-шаблонов. --VladXe (обс.) 19:28, 10 ноября 2017 (UTC)
  • Первое и четвертое тестовые обсуждения запущены на ВП:КУ с приглашением Проект:Футбол и Проект:Спорт для обсуждения частных вариантов {{footy-bio-stub}} и {{cycling-bio-stub}} (частные варианты этих шаблонов часто встречаются среди малоиспользуемых). Alex Spade 08:46, 11 ноября 2017 (UTC) UPD: Alex Spade 20:07, 15 ноября 2017 (UTC)
  • Второе, третье и пятое тестовые обсуждения запущены на ВП:КУ с приглашением Проект:Медицина для обсуждения частных вариантов по разделам медицины (которые также часто встречаются среди малоиспользуемых). Alex Spade 12:40, 12 ноября 2017 (UTC) UPD: Alex Spade 17:24, 18 ноября 2017 (UTC)

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

  • (+) За, так сложилось, что за качество статей отвечают проекты. Могут быть проекты без стаб-шаблонов (например статусные и технические), но стаб-шаблон без проекта существовать не должен. --VladXe (обс.) 22:35, 6 ноября 2017 (UTC)
  • Да, так и есть, и было всегда.--Abiyoyo (обс.) 22:40, 6 ноября 2017 (UTC)
  • Да, конечно —be-nt-all (обс.) 00:07, 7 ноября 2017 (UTC)
  • (−) Против Стаб-шаблоны не для проектов, а для всех. — Igel B TyMaHe (обс.) 09:25, 7 ноября 2017 (UTC)
  • (−) Против per Igel B TyMaHe.--Dmartyn80 (обс.) 15:32, 7 ноября 2017 (UTC)
  • (−) Против, по крайней мере в формулировке VladXe (привязка = исключение ситуации "стаб-шаблон без проекта"). Огромное количество статей не принадлежит никаким проектам, требовать создания новых проектов только для формальной привязки к ним стаб-шаблонов бессмысленно. --Шуфель (обс.) 16:04, 7 ноября 2017 (UTC)
    • Этого никто не предлагает. Стаб-шаблоны без проекта влекут не создание проекта, а объединение с более общим стаб-шаблоном.--Abiyoyo (обс.) 16:45, 7 ноября 2017 (UTC)
    • Подтверждаю: если проекта для стаб-шаблона не существует, то он объединяется с наиболее близким по смыслу из «привязанных» стаб-шаблонов. Какой смысл акцентировать снимание, что статья по этой теме не закончена, если вероятность её целенаправленного дописывания — бесконечно мала величина? Для таких случаев есть Ш:rq|empty. --VladXe (обс.) 11:50, 9 ноября 2017 (UTC)
      • Если не существует активного проекта по теме, то скорее всего "наиболее близким по смыслу" будет шаблон такой степени общности, что ни к какому осмысленному проекту его привязать будет невозможно. Стаб-шаблон {{zoroastrianism-stub}} вполне можно признать слишком "мелким" и укрупнить его вместе с некоторым количеством схожих до вполне логичного и близкого по теме "заготовка статьи о религии", но проекта для такого стаба опять нет - куда будем объединять дальше? Куда вы привяжете: {{family-stub}} (Проект:Генеалогия неактивен), {{state-stub}} (Проект:Политика неактивен), {{rabbi-stub}} (Проект:Иудаика неактивен)? --Шуфель (обс.) 11:05, 12 ноября 2017 (UTC)
        • Отсутствие активности в проекте не мешает ни его существованию, ни существованию стаб-шаблона на его основе. Из каждого правила можно сделать исключение, для этого и осуждаем. --VladXe (обс.) 11:24, 12 ноября 2017 (UTC)
          • Не вижу принципиальной разницы между тем, как именно будет воплощен принцип "исключить ситуации "стаб-шаблон без проекта"" - использованием существующего, но неактивного проекта, или созданием нового фиктивного. Говорить об "исключениях" при этом не приходится, в исключения попадут как бы не половина статей-заготовок. Другое дело, что можно было бы разделить решение на два потока: привязать стаб-шаблон к проекту в тех случаях, когда это возможно сделать очевидным способом; и отдельно обсудить, что делать с "беспроектными" стаб-шаблонами (и тут решение не обязано следовать логике, применяемой для "прокетных" заготовок; можно ограничится причесыванием под некий универсальный критерий, как предлагает следующий пункт, а можно и попросту свести к номенкалтуре rq-категорий). --Шуфель (обс.) 12:09, 12 ноября 2017 (UTC)
  • (−) Против.--Arbnos (обс.) 01:26, 10 ноября 2017 (UTC)

Необходимо создать универсальные требования для существования стаб-шаблона[править код]

Проекты должны определять, сколько и какие стаб-шаблоны им нужны[править код]

(если нет, то свой вариант того, кто и как должен следить за количеством стаб-шаблонов)

Следует заменить всю совокупностью стаб-шаблонов на один[править код]

(уточнение после комментария Alex Spade: вместо {{нечто-stub}} писать{{stub|нечто}}, изображение, выводимая информация и целевая категория выбирается по значению первого неименованного параметра. Целевая категория является подкатегорией К:Незавершённые статьи или ей самой при нулевом значении.) --VladXe (обс.) 11:50, 9 ноября 2017 (UTC)

Следует вообще отказаться от стаб-шаблонов в пользу других инструментов[править код]

речь идёт о шаблонах проектов на СО статей и (или) тем шаблона rq с параметром empty.

  • (−) Против — пока нет, к стаб-шаблонам привыкли как и редакторы, так и читатели. --VladXe (обс.) 22:35, 6 ноября 2017 (UTC)
  • (−) Против, штука на самом деле полезная, в том числе как призыв к читателю включится в процесс правки ВП —be-nt-all (обс.) 00:07, 7 ноября 2017 (UTC)
  • Отложить вопрос до написания скрипта, поволяющего удобно редактировать и отображать содержимое плашек проектов в ОП. Когда напишут - можно отказаться, т.к. дублирование.--Abiyoyo (обс.) 22:43, 6 ноября 2017 (UTC)
    Кстати, см.: d:Q17580680. Будущее тут. Как оно будет отображаться в ВП — вопрос отдельный. Надо в эту сторону смотреть. Но, повторяю, это сейчас обсуждать преждевременно за неимением технических средств.--Abiyoyo (обс.) 00:38, 7 ноября 2017 (UTC)
    Подобный вариант можно только поддержать, но пока оно всё вилами на воде —be-nt-all (обс.) 18:06, 10 ноября 2017 (UTC)
  • (=) Воздерживаюсь Возможно, наоборот - отказаться от других инструментов в пользу стаб-шаблонов. — Эта реплика добавлена участником Igel B TyMaHe (ов)
  • (+) За, конечно. Система стаб-шаблонов не просто бесполезная, а даже немного вредящая: в огромном множестве статей стаб проставляется участниками вместо {{rq}}, который указывал бы на конкретные, а не абстрактные недостатки статьи. Эффективность стаб-шаблонов в привлечении читателя к редактированию статей ничем не подтверждается, и уж тем более она никем не сравнивалась с аналогичной эффективностью rq. Итого имеем ненужную дублирующую систему, зато привычную и с красивыми картиночками. Удалить. ØM 11:35, 7 ноября 2017 (UTC)
  • (+) За. Коллега ØM прав, + при нынешних требованиях и тенденциях КУ то, что именовалось стабом лет этак 10 назад, ныне уедет на быстрое.--Dmartyn80 (обс.) 15:32, 7 ноября 2017 (UTC)
  • (=) Воздерживаюсь Возможно, но после конкретизации "других инструментов" --Шуфель (обс.) 16:04, 7 ноября 2017 (UTC)
  • Стаб-шаблоны никакой информации просто не несут. Тот, кто знает, как доработать, доработает хоть ИС без всяких шаблонов, кто не знает - тому стаб-шаблон никакой информации кроме «кто-то там считает эту статью не очень хорошей» не несёт. Фил Вечеровский (обс.) 19:16, 8 ноября 2017 (UTC)
  • (−) Против.--Arbnos (обс.) 01:26, 10 ноября 2017 (UTC)

Следует ли создать отдельную площадку для координирования действий по реформе стаб-шаблонов?[править код]

(против — этой темы вполне достаточно, или за, то указать где)

Итог

Что-то мы (и я) забыли про площадку Проект:Незавершённые статьи, посему не стоит множить сущности. Если нужна площадка за рамками данного форума, то она уже есть. Alex Spade 17:26, 12 ноября 2017 (UTC)

Следует ли создать отдельную площадку для изменения номенклатуры стаб-шаблонов?[править код]

Итог

Что-то мы (и я) забыли про площадку Проект:Незавершённые статьи, посему не стоит множить сущности. Если нужна площадка за рамками данного форума, то она уже есть. Alex Spade 17:26, 12 ноября 2017 (UTC)

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

Как часто бывает, на абстрактные вопросы получены чёткие ответы, а в конкретных вопросах консенсуса нет. Итак: 1) Реформе стаб-шаблонов быть, их количество должно быть уменьшено. 2) Идея о привязке стаб-шаблонов к проектам осталась без консенсуса, поэтому интересоваться мнением проектов о том, какие стаб-шаблоны им нужны, в ходе реформы нужно, но окончательное решение будет приниматься по другим критериям. 3) Для координирования реформы выбрана основная площадкаПРО:Незавершённые статьи‎, и дополнительная (на случай возражения активных участников) — новый подпроект ПРО:Качество. 4) Сообщество поддержало идею о выработке нормативного документа, регулирующего правила создания (наличия) и содержание стаб-шаблонов. Так как тема начата на этом форуме, проект нормативный документа будет представлен здесь же позже. 5) Единому стаб-шаблону быть. Каким ему быть — это отдельный вопрос, который будет решаться в другом месте (см. п. 4). 6) По прежнему нет консенсуса на идею об полном отказе от стаб-шаблонов. --VladXe (обс.) 17:08, 13 ноября 2017 (UTC)

Если в течение недели предварительный итог не будет оспорен или по открытым вопросам не будет установлен другой консенсус, то итог становится окончательным. --VladXe (обс.) 17:08, 13 ноября 2017 (UTC)

перенесено из подраздела выше --VladXe (обс.) 20:00, 20 ноября 2017 (UTC)

и возращено обратно, ибо соот. тестирование касалось именно соот. подтопика. Alex Spade 22:11, 20 ноября 2017 (UTC)

Итог разумеется оспорен, так как:

  • 1) Решать глобальные проблемы, затрагивающие 400 тысяч статей на основе "мини-опроса" 8 человек я считаю за пределами "фиксации глобального консенсуса сообщества". Учитывая, что у нас в районе 200-250 метапедически активных участников, 8 человек не могут определить масштабные изменения, затрагивающие большое количество статей.
  • 2) Обсуждение явно должно длиться более недели, участники ВП не всегда каждый день онлайн.
  • 3) Голосование - в принципе зло, а по вопросам масштабных изменений - тем более. Итог (как и сам опрос) должен анализировать аргументы, по которым участники считают необходимым запустить реформу или выбирать ту или иную площадку для её координирования.
  • 4) Я уже не говорю о том, что так как предлагаются изменения в правилах использования стаб-шаблонов и их реформирование/ограничение/удаление на основе изменения правил, то все обсуждения должны вестись на специальном месте - на форуме ВП:Ф-ПРА (хотя бы потому, что многие просто не заходят на данный форум, при том что регулярно мониторят Ф-ПРА).

Посему из данного "опроса" (точнее суперблиц-мини-голосования) не может быть сделан вывод о каком-либо консенсусе сообщества. TenBaseT (обс.) 08:56, 21 ноября 2017 (UTC)

  • 1) А если больше вопрос никого настолько не интересует? Что, если и в опросе выскажутся те же 8-10 человек? Заблокируете любое принятие решений по этому вопросу?
  • 4) Неоднократно высказывавшееся вами утверждение, что за одним из шести стандартных форумов из шапки следит намного больше участников, чем за другим из шести стандартных форумов из шапки, неверно. Как видно из этой статистики, число следящих за ними отличается процентов на пять, а среди всех шести стандартных форумов из шапки Ф-ПРА по слежению за ним - предпоследний. Тогда уж нужно вести обсуждение на Ф-О. MBH 09:59, 21 ноября 2017 (UTC)
    • 1) Я не думаю, что в нормально проведенном опросе в нормальные временные рамки (а не блиц за неделю) и с нормальным оповещением сообщества выскажутся только те же 8 человек, наверняка представительность сообщества там будет намного намного выше. Зачем же блокировать решение сообщества ?
    • 4) То, что страница формально находится в списке наблюдения не обязательно обозначает, что участник реально просматривает ведущиеся там обсуждения. Так что эта статистика реально не дает представления о том, сколько участников следит за обсуждениями. В любом случае пункт 4 идёт "в бесплатное дополнение" к первым трём, которые наиболее важны. TenBaseT (обс.) 10:22, 21 ноября 2017 (UTC)
  • «Если мнение не совпадает с моим, то оно неправильное». Это очередное забалтывание вопроса, реформа будет продолжаться с использованием стандартных процедур Википедии. --VladXe (обс.) 18:01, 21 ноября 2017 (UTC)
    • Вы можете продолжать всё что угодно (в пределах правил), только не нужно оперировать "якобы имеющимся консенсусом сообщества на реформу стаб-шаблонов", потому как его не имеется. TenBaseT (обс.) 19:47, 21 ноября 2017 (UTC)
      • Это сугубо Ваше мнение и установленный консенсус по вопросам «реформе быть» и «нужен один универсальный стаб-шаблон» оно не отменяет по ВП:НЕБЮРОКРАТИЯ. Приведите ещё 3 единомышленников для его отмены по арифметическому признаку. --VladXe (обс.) 20:31, 21 ноября 2017 (UTC)
        • Так нету "установленного консенсуса" сообщества (междусобойчик таким не является), поэтому несуществующего отменять я не собираюсь. И уж "арифметический признак" в вопросах консенсуса - безусловное зло :) Посему любые изменения в правилах, основанные на этом "псевдо-итоге" будут оспорены и отменены, как "подлог консенсуса сообщества". И моё личное мнение по теме не играет ни малейшей роли. TenBaseT (обс.) 20:43, 21 ноября 2017 (UTC)
      • Желаете установить новый консенсус — проводите новый «правильный» опрос. Только учтите, что викисообщество уже устало переливать из пустого в порожнее. Пока итог по нем не проведён, действует этот итог. Кстати, тот итог я оспорю, если количество голосов в новом опросе будет меньше 10. --VladXe (обс.) 20:35, 21 ноября 2017 (UTC)
        • Лично я не собираюсь устраивать опросы, и определять "новый консенсус", так как старый найден уже 12 лет назад и пока неизменен, Ваш "оспоренный итог" его не поменял и разумеется он не действует. Успехов. TenBaseT (обс.) 20:43, 21 ноября 2017 (UTC)
  • Если считаете, что Ваше единственное мнение превышает мнение 8-10 высказавшихся человек, то у Вас административный восторг и его надо лечить. --VladXe (обс.) 18:03, 21 ноября 2017 (UTC)
    • Моё мнение (единственное или нет) не имеет ни малейшего отношения к теме подведения итога о консенсусе на основе этой "блиц-голосовалки". А "административный восторг" (если он и был), прошёл месяца через два после получения флага администратора, то есть лет 7 назад. TenBaseT (обс.) 19:47, 21 ноября 2017 (UTC)
  • Коллеги VladXe и TenBaseT, а может стоит просто подправить итог, чтобы всё-таки зафиксировать промежуточные результаты? Например, смягчить формулировки или сделать оговорку о том, что непосредственная реализация единого стаб-шаблона (5) будет предварена развёрнутым обсуждением и утверждением на Ф-ПРА нормативного документа (4). И меняем «Оспоренный итог» обратно на «Итог». Окей? —Alexandrine (обс.) 10:12, 22 ноября 2017 (UTC)
    • Если переписать итог без "установления консенсуса сообщества" - то почему бы и нет, я собственно не против выработки нового единого стаб-шаблона, а итог оспорил только после того, как несколькими темами выше мне попытались заткнуть рот именно "зафиксированным консенсусом сообщества". Ежели топик-стартер перепишет итог в духе "есть мнение нескольких участников, что ..." и далее по тексту - в этом случае я возражать не буду. Ну или, если топик-стартер захочет, могу сам подвести итог в таком духе. TenBaseT (обс.) 11:17, 22 ноября 2017 (UTC)
      • А вот не хочу. Вы так ратовали за полное соблюдение буквы правил, наплевав на дух, что организовывайте-ка новый полноценный опрос, отвечая на реплики «да сколько ж можно одну тему мусолить», ждите 1-2 месяца и подводите полноценный итог. Раз Вы поставили своё мнение выше мнения коллектива, то оно заслуживает либо полного одобрения этим коллективом, либо спуска в утиль. А пока ПРО:Незавершённые статьи‎ будет делать своё дело на законных основаниях. --VladXe (обс.) 11:42, 22 ноября 2017 (UTC)

Ограничение номенклатуры stub-шаблонов[править код]

В рамках обсуждения Википедия:Форум/Архив/Общий/2017/10#Невесёлые картинки было в целом поддержано желание иметь вариант stub-шаблоны, который позволяет объединять темы. Вместе с тем, текущая номенклатура stub-шаблонов (1900+) делает попытку создания такого шаблона (с полной эмуляцией текущего разнообразия тем) крайне затратной. Поэтому предлагается обсудить возможность/целесообразность введения каких-либо ограничений на разнообразие stub-шаблонов. Можно, например, ввести требование по минимальному число использований (аналогичное решение есть например для userbox шаблонов - не менее 3): из 1900+ stub-шаблонов ~140 используются 5 или менее раз, ~340 - 10 и менее раз, ~600 - 20 и менее раз. Или по аналогии с {{rq}} ограничить число тем (у rq их порядка 40). Возможно есть и другие варианты. Alex Spade 16:36, 3 ноября 2017 (UTC)

отсечение по числу включений[править код]

  • Овчинка выделки не стоит. Это же не решит проблему многообразия, ведь даже если убрать встречающиеся менее 5 раз (а 5 раз — это уже достаточно), сократить общее количество удастся менее чем на 10 процентов. --Good Will Hunting (обс.) 16:41, 3 ноября 2017 (UTC)
  • Встречный вопрос — а как часто на одной странице вообще используется более чем один стаб-шаблон? --Good Will Hunting (обс.) 16:41, 3 ноября 2017 (UTC)
    • Встречается, например стаб о вымершем животном обычно имеет шаблон стаба палеонтологии и бионауки, изучающий конкретный класс или тип (ихтио-, орнито-, терио- и прочие -логии). Тоже самое в геостабах: тип объекта и государство или регион. --VladXe (обс.) 16:53, 3 ноября 2017 (UTC)
  • Я посмотрел опыт ан-вики коллег, и если я правильно понял проект en:WP:STUBS (с подстраницами), то несмотря на намного большую номенклатуру, они также стараются её ограничивать. В частности - новые варианты stub-шаблонов рекомендуется обсуждать (чего у нас практически нет); целесообразность уже существующего конкретного stub-шаблона (stub-категории, считая вместе с подкатегориями) на менее 30 статей обсуждалась в обязательном(?) порядке, а менее 50-60 статей - в рекомендательном порядке. Может нам также хотя бы разок пройти (через КУ или КОБ)? В этом случае, например, {{Road sign-stub}} (4 включения) обязан пройти обсуждение, а {{Ballet-stub}} (11 включений) уже нет - поскольку у него есть подшаблон {{Ballet-bio-stub}} (60+ включений). Alex Spade 11:25, 5 ноября 2017 (UTC)
  • Если нужно быстрое решение по цифре отсечения малого числа включений, то она давно есть, см. п.5. тут: Википедия:Совет вики-проектов/Руководство/Объединение. Это 25 статей. Давно уже работаем именно так, и это вполне консенсусная де-факто цифра, до той поры, пока не решился вопрос с полным соответствием стабов вики-проектам. --Abiyoyo (обс.) 17:31, 6 ноября 2017 (UTC)
    • Сразу вопрос: 25 статей по теме или 25 стабов по теме? --VladXe (обс.) 20:26, 6 ноября 2017 (UTC)
      • Стабов.--Abiyoyo (обс.) 11:39, 7 ноября 2017 (UTC)
        • Консенсусно текст руководства предписывает заменять один шаблон другим, когда каких-то шаблонов мало, однако объединяются два проекта. Однако это не то, что подразумевалось под «отсечением» в данной теме: насколько я понял, предлагалось просто запретить конкретные очень малоиспользуемые стаб-шаблоны и удалять их. И если так, то цифра в 25 шаблонов ни капли не консенсусна: есть огромное количество стаб-шаблонов с менее чем десятью включениями. --Good Will Hunting (обс.) 12:21, 7 ноября 2017 (UTC)
          • Ясное дело, что надо не удалять, а заменять более общим. Едва ли кто предлагает удалить вовсе из статей без альтернативы другого, более общего шаблона.--Abiyoyo (обс.) 12:52, 7 ноября 2017 (UTC)
          • Планка - повод для обсуждения, а не для автоматического удаления. Например, как я сказал чуть выше, на первой стадии оптимизации нет смысла в удалении {{Ballet-stub}}, поскольку у него есть подшаблон {{Ballet-bio-stub}}, а вот некоторый смысл объединить эти шаблоны может и есть. Alex Spade 18:37, 7 ноября 2017 (UTC)

автоматический stub[править код]

  • Было бы здорово использовать просто шаблон стаб, который в зависимости от категории или категорий, в которых находится статья, сам бы показывал, на какую тему это стаб. --Good Will Hunting (обс.) 19:13, 3 ноября 2017 (UTC)
    • тогда уж не от категорий, но от значения свойства "частный случай" на Викиданных. ShinePhantom (обс) 07:05, 4 ноября 2017 (UTC)
      • Против — Ш:stub более детализирован, чем свойство "частный случай". --VladXe (обс.) 13:08, 4 ноября 2017 (UTC)
        • мы можем их детализировать хоть до отдельных квантов. Толку то с того? Ни на букву энциклопедия от этого полнее или точнее не становится. Но так хоть какой-то порядок будет. Вместо желания отдельных участников создавать по велению собственной пятки стаб шаблоны "про рыжих певцов, владеющих мотоциклом, проживающих в Испании и говорящих на итальянском" ShinePhantom (обс) 18:52, 5 ноября 2017 (UTC)
          • Нет, я сравниваю по одной части бытия — зоологических таксонах: в Викиданных всего 2 варианта, а в рувики стаб-шаблонов — 19 и из них только 3 выглядят излишними, ещё 5-7 можно объединить с потерей детализации. --VladXe (обс.) 19:20, 5 ноября 2017 (UTC)
            • сколько активных зоологических проектов в рувики? ShinePhantom (обс) 05:03, 6 ноября 2017 (UTC)
              • 4 «Вечно живых» (в т. ч. ПРО:Биология, отдельной зоологической площадки нет), ещё 1 — вообще новый (если кто скажет, что человек — не животное, в того можно кинуть тапком). --VladXe (обс.) 08:58, 6 ноября 2017 (UTC)
                • и для кого предназначен зоопарк из остальных 15 шаблонов? ShinePhantom (обс) 09:02, 6 ноября 2017 (UTC)
                  • А Вам не приходило в голову, что специализированные вопросы можно обсуждать на общих площадках? «Чисто» зоология, даже «чисто» вирусология и т. д. в ПРО:Биология постоянно обсуждаются и никто на такие вопросы в общем проекте не возмущается. А стабы по наукам очень хорошо делятся. Раз уж наука (!) есть, то уж шаблон/параметр в шаблоне с таким названием быть должен, ибо указан в АИ. Но в тоже время согласен, что стаб о пчёлах — лишний, энтомологию делить вряд ли стоит (хотя муравьями в рувики занимаются на профессиональном уровне, поэтому я бы лично [в знак заслуг перед проектом] этот шаблон/параметр сохранил). --VladXe (обс.) 09:48, 6 ноября 2017 (UTC)
                    • именно это мне в голову и пришло. Если есть десять шаблонов, но работа по ним ведется на одной единственной площадке - то почему их десять? ShinePhantom (обс) 14:53, 7 ноября 2017 (UTC)
                      • ну мои трения с участниками проекта известны, но если кого интересуют вирусы, а не парнокопытные, ему поиск стабов о вирусах не повредит. Но неужели вопрос не решаем? На тех же викиданных? Уж очень идея простого шаблона привлекательной кажется. —be-nt-all (обс.) 17:56, 10 ноября 2017 (UTC)
                      • Потому что это позволяет: а) объединить стабы в 10 разных категориях по достаточно узким, но значимым темам (есть любители писать про шпинат, а есть — про свиной хрящик); б) ещё раз визуализировать тему статьи, например, для биологии — на уровне наук, изучающих отдельные царства/типы и даже классы для позвоночных. --VladXe (обс.) 18:08, 10 ноября 2017 (UTC)
    • Согласен, stub-категория может по-идее подцеплять тему из Викиданных, но кроме разнообразия тем (swtitch 1) у нас наблюдается разнообразие категорий (switch 2), так что если бы мы объединили параметры article и category - было бы проще. Последующее рассуждение выделено в отдельный подтопик. Alex Spade 07:45, 4 ноября 2017 (UTC)
  • Есть другой вариант: единственный автоматический стаб-шаблон. Просто {{stub}}. У нас есть Викиданные, есть категоризация. С первым понятно - определить ключевые поля - и вперед с песнями. Второе - не знаю, может ли шаблон прочитать категорию статьи, вроде, нет. Мог бы - всё стало бы ещё более легко и приятно. — Igel B TyMaHe (обс.) 09:56, 4 ноября 2017 (UTC)
  • На основе категорий в статье не сделать по техническим причинам. Придется парсить всю страницу, это сложно и overkill. На основе ВД можно и несложно, но проблематично из-за множества значений instance-of на ВД. Лучше свести к проектам или как минимум ограничить числом включений (не менее 25/50/100).--Abiyoyo (обс.) 18:15, 6 ноября 2017 (UTC)
    • Т. е. нужен то ли опрос, то ли отдельный проект, в котором метапедисты выработали бы а) критерии существования конкретного стаб-шаблона, б) приемлемый список стаб-шаблонов. Уже потом можно объединять, перерабатывать в параметр шаблона проектов и т. д. --VladXe (обс.) 19:24, 6 ноября 2017 (UTC)
      • Если формально привязать к числу включений, то не нужно ничего, это простой показатель. Если привязывать к вики-проектам, то есть ВП:СОВЕТ, который отслеживает активность проектов и занимается др. вопросами межпроектной координации. Актуальный список активных проектов тут: Википедия:Совет вики-проектов/Каталог проектов/Полный (см. выделенные зеленым цветом). Если есть желание заниматься проектами — присоединяйтесь.--Abiyoyo (обс.) 20:27, 6 ноября 2017 (UTC)
        • А вот здесь (−) Против, т. к. считаю, что в пределах одного проекта могут обсуждаться несколько направлений (практически подпроектов), каждое из которых заслуживает своего стаб-шаблона и стаб-категории. Есть довольно много экзопедистов, которые посвящают себя только статьям в одной-двух тематиках и применяют существующие инструменты, а вот упорядочивание и изменение последних им не интересно. Вы же хотите вообще лишить таких людей одного из инструментов. --VladXe (обс.) 20:34, 6 ноября 2017 (UTC)
          • Как на практике отделить тематику с активными авторами от неактивных? Вот есть конкретный критерий. Другого вы не предложили. Прежде чем говорить «против», да еще и с круглым кружочком красного цвета, надо предлагать работающую альтернативу. Отвергаешь — предлагай. Правило номер один. Иначе все эти «против» ничего не стоят. Тут не голосование. Если проекту нужно несколько шаблонов — это не проблема. Пусть только они явно заявят это. Сами. А не со стороны кто-то будет думать «авось кому надо», хотя этого кого-то днем с огнем не сыщешь.--Abiyoyo (обс.) 20:41, 6 ноября 2017 (UTC)
            • Так надо место, где проекты могут предложить своё решение, а также объявление, что именно от проекта зависит, какие стаб-шаблоны у них останутся. Представьте, если с каждого проекта в эту тему посыпятся предложение что оставить, а что удалить, сколько того обсуждения будет? --VladXe (обс.) 20:46, 6 ноября 2017 (UTC)
              • Эти места есть. Их даже три. 1. Заглавная страница проекта. 2. Страница категорий незавершённых статей (см. напр. Категория:Незавершённые статьи о биологах). 3. Общий список стаб-шаблонов с разбивкой по проектам: Проект:Незавершённые статьи/Шаблоны. Есть еще четвертое место, если и этого мало — здравый смысл в голове участников. Короче, места есть. А вот нужен ли проекту тот или иной шаблон, и как сократить — решается в рабочем порядке. Усложнять не нужно. Спросили на СО проекта — «что оставить?» и сократили по ситуации. Из опыта hint: в половине случаев после обращения на СО проекта ответа не будет. Значит, можно сокращать до одного.--Abiyoyo (обс.) 20:56, 6 ноября 2017 (UTC)
                • С последним я согласен — если проект не отреагировал, то ему оставляют 1 стаб-шаблон, одноимённый проекту. А если проект отреагировал и принял решение, как ему об этом решении сообщить? Или Вы лично все проекты через месяц после оповещения просмотрите, итоги в эту тему подобьёте? --VladXe (обс.) 21:12, 6 ноября 2017 (UTC)
                  • Я лично не обещаюсь. Но я тут и не один. Процедуру придумать несложно. Во-первых, участники проектов сами могут озаботиться вопросом и, упреждая проблемы, сами объединить зоопарк своих стабов до разумного числа. Во-вторых, в ВП нет ничего необратимого. Если кто сократит «не так», можно отменить, учитывая, что тут не требуется админдействий (разве что КБУ.К1, но это действие отменяемое в порядке ПС). В третьих, можно выносить шаблоны на КУ, где участники могут отписаться. Если шаблонов нет в их СН, то можно сделать уведомление на форуме, мол, планируем зачистку, если вам что нужно, добавьте в СН. В-четвертых, можно и на СО проектов перенести обсуждения, в рабочем порядке. То есть договориться, что уч-ки, занимающиеся объединением, должны спросить на СО. Граничное условие — не мене 25/50/100 разумных включений (чтобы отдельные несговорчивые проекты не упорствовали по мелочам). Короче, это все рабочие вещи, они решаемы.--Abiyoyo (обс.) 21:26, 6 ноября 2017 (UTC)

stub vs плашки проектов[править код]

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.
  • Когда-то вообще хотели от них отказаться, заменив на шаблон проекта с IV-м уровнем развития статьи. Может пора развить шаблон {{Статья проекта}}, позволив добавлять по 1-3 подпроекта (включая несуществующие), что позволить удалить весь зоопарк стабов? --VladXe (обс.) 16:48, 3 ноября 2017 (UTC)
    • Французский стаб-шаблон fr:Modèle:Ébauche позволяет в одном шаблоне задать до 6 тематических параметров (fr:Discussion module:Bandeau/Ébauche/Documentation - список параметров). 176.59.5.88 18:23, 3 ноября 2017 (UTC)
      • А нужны ли служебные шаблоны, объясняющие внутреннюю кухню Википедию, в самой статье? Rq должно хватить, к тому же в нём есть соотв. параметр. --VladXe (обс.) 18:45, 3 ноября 2017 (UTC)
      • Хотя в рувики уже есть опыт замены 100500 шаблонов на 1-2 — #Список языков на странице участника, но если там список языков всё-таки конечен и определяется в Медиавики, то делить темы бытия для стабов можно бесконечно. Представляете какая нагрузка будет у инженеровпо развитию этого монстрошаблона? --VladXe (обс.) 19:59, 3 ноября 2017 (UTC)
        • Это не единственный пример. Ибо зачем делить темы бесконечно - это stub-шаблоны, они по-определению вре́менные. У нас есть ещё как минимум два опыта ограничения именно по темам/номенклатуре - это тот же параметр topic в {{rq}} (соот. тем всего 40+ против 1900+) и ограниченная номенклатура свободных лицензионных шаблонов (по сравнению с Викискладом) - где действует тот же смысл ограничения - зачем сильно развивать локальную номеклатуру, если предполагается, что файлы будут перенесены (файлы размещены на вре́менной основе). Alex Spade 07:44, 4 ноября 2017 (UTC)
    • VladXe, уже развили. Параметр «подпроект» в плашке имеется.--Abiyoyo (обс.) 21:06, 6 ноября 2017 (UTC)
  • Нужно возвращаться к вопросу по ограничению использования стабошаблонов и удалению большей их части, в духе итога Абийойо по опросу о стабошаблонах, который (итог) был саботирован Руматой. MBH 02:12, 4 ноября 2017 (UTC)
  • Вопрос уже единожды был решен. Стаб-шаблоны оставить для активных вики-проектов. Стаб-шаблоны нужны для доработки коротких статей. Ок. Но ради одного участника держать шаблон накладно. А трое уже могут собраться в вики-проект. Следующий этап рассуждения — уже есть проектные плашки, дублирование избыточно и не нужно. Таким образом, на первом этапе следует сохранить стаб-шаблоны эквивалентные проектам отсюда: ВП:КАТАЛОГ. А затем постепенно упразднить в пользу проектных плашек. К котрым также надо написать скрипт для простого редактирования из ОП, а также объединить проектные плашки в единый шаблон. Это нормальное, последовательное решение, с которым согласно большинство участников, кроме отдельных ныне неактивных. Подробности см. в ВП:ТЕХСТАБ (Википедия:Опросы/Технические и организационные проблемы stub-шаблонов#1. Введение).--Abiyoyo (обс.) 17:24, 6 ноября 2017 (UTC)
    • И где почитать консенсусное решение? --VladXe (обс.) 19:25, 6 ноября 2017 (UTC)
      • Формально-консенсусного нет. Было решение которое устроило всех, кроме одного участника. Тот подал заявку в АК, а АК у нас нынче такой, что в любой непонятной ситуации предпочитает сказать «обсуждайте дальше». По сути все согласились. Но формально консенсуса нет. Но тут уже нет смысла вспоминать прошлое, лучше решить вопрос сейчас.--Abiyoyo (обс.) 19:32, 6 ноября 2017 (UTC)
  • Шаблоны проектов консенсусно живут на СО страниц (и даже там всё ещё некоторых раздражают) шаблон стаб — в ОП, и его цель, в числе прочего — «вербовать» волонтёров, новых редакторов Википедии. —be-nt-all (обс.) 18:00, 10 ноября 2017 (UTC)

объединение параметров article и category[править код]

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Как вариант упрощения ситуации предлагается рассмотреть возможность/целесообразность объединения параметров article и category (отказа от параметра article). Единственный минус - в тексте сообщения мы потеряем вики-линк на тему, но, имхо, тема так или иначе должна фигурировать в определении статьи и/или карточке и/или последующем тексте. Т.е. если надо уточнить в стабе с {{russia-geo-stub}}, что такое география России (что такое Россия) - это нужно делать в начале статьи, а не в конце. Кстати, в ан-вики таких ссылок в stub-шаблонах нет (en:Template:Russia-geo-stub), дабы они не создавали доп.нагрузки на "Ссылки сюда". Alex Spade 13:04, 4 ноября 2017 (UTC)

Т.е., например, было

{{Stub-meta
|article       = о [[сельское хозяйство|сельском хозяйстве]]
|category      = о сельском хозяйстве
|image         = Watermelon.svg
|size          = 32
|alt           = Арбуз
}}

cтанет

{{Stub-meta
|category      = о сельском хозяйстве
|image         = Watermelon.svg
|size          = 32
|alt           = Арбуз
}}
  • Ну хорошо хоть Черчилля убрали. Retired electrician (обс.) 22:32, 5 ноября 2017 (UTC)
  • (−) Против: если тривиальное сельское хозяйство знает каждый (во всяком случае, обязан знать), то ту же орнитологию вряд ли 100 % читателей воспринимают, как науку о птицах. Название предмета статьи и науки, его изучающей, для всех стабов — нетривиальный список, поэтому викификация не повредит. --VladXe (обс.) 09:59, 6 ноября 2017 (UTC)
    • Если участник не знает, что такое орнитология, то всем будет лучше, если статьи о птицах он править не станет. Фил Вечеровский (обс.) 11:45, 6 ноября 2017 (UTC)
      • Вот полностью с Вами не согласен — если у участника RU-5 и он увидел орфо- или пунктуационную ошибку, то пусть даже в сверхспециализированной статье по молекулярной биологии или математики её исправит. --VladXe (обс.) 11:54, 6 ноября 2017 (UTC)
        • Во-первых, участник с ru-5, не имеющий представления о химии, имеет полное право считать, что сульфит - это то ли сульфид, то ли сульфат с орфографической ошибкой и будет в статье по химии не нужен. А вот чтобы исправить «водаплавающий» на «водоплавающий» не нужно ни знать, чем занимается орнитология, ни даже знать, что это стаб. Фил Вечеровский (обс.) 14:26, 6 ноября 2017 (UTC)
  • годится как мера по упрощению объединения. Да, викификация per se не так уж и плоха, но усложняет техническую сторону вопроса. Лучше отказаться ради простоты.--Abiyoyo (обс.) 18:09, 6 ноября 2017 (UTC)
  • Я посмотрел на ан-вики и наши шаблоны по-больше. Я по-прежнему поддерживаю объединение параметров, но нужно таки отметить, что а) в некоторых ан-вики-шаблонах есть уточняющий викилинк, б) так просто объединить параметры автоматически не всегда получиться - у наших шаблонов может быть весьма разные article и category - придётся заметную часть разбирать вручную. Alex Spade 07:17, 7 ноября 2017 (UTC)

Итог (объединение параметров article и category)[править код]

Не получится, я забыл (не обратил внимание), что в article может быть понятие в ед.числе (например, о реке, о химике), а в категории тогда будет во мн.числе (соответственно, о реках, о химиках). Alex Spade 12:17, 12 ноября 2017 (UTC)