Википедия

Арбитраж:Шаблоны-карточки персонажей/Набор рабочей группы/Разбор кейсов

< Арбитраж:Шаблоны-карточки персонажей‎ | Набор рабочей группы

Эксперимент Iniquity

Вопросы

1. Что вы понимаете под выражением «форк шаблона», «дубликат шаблона»?
2. Почему дубликаты шаблонов могут быть полезны?
3. Почему дубликаты шаблонов могут быть вредны?

Участник sas1975kr

1. Что вы понимаете под выражением «форк шаблона», «дубликат шаблона»?
Форк шаблона - созданный на основании текущего шаблона другой шаблон, дающий другую функциональность или другое оформление.
Дубликат шаблона - выполняющий сходную функцию, может отличаться оформлением и функционалом, а может не отличаться.
Сама по себе формулировка вопроса таком ключе ИМХО не очень удачна. Это накладывает ограничения на ответы п.2 и п.3. Есть процесс унификации, когда идет объединение шаблонов. Этот процесс также важен, так как является одной из причин создания форков, но мы его полезность и вредность получается не обсудим. И есть процесс связи карточек с викиданными. Оба процесса больше чем вопрос дублей шаблонов и что-то можем пустить.
2. Почему дубликаты шаблонов могут быть полезны?
2.1 Для некоторых редакторов важно оформление именно в своем варианте. Не важно в по функционалу или оформлению. Так как я считаю шаблон всего лишь способом оформления статьи, то чтобы не демотивировать авторов я допускаю создание альтернативного оформления. Путем настроек текущего шаблона или создания дубликата, если первое не реализуемо. Есть нюанс что процесс не должен быть полностью хаотичным. Хотелось бы обоснования. Проблема в том, что под этим каждый понимает своё.
2.2 Внесение в существующие шаблоны каких-либо изменений сопряжено с трудностями. Как по причине сложности нахождения консенсуса. Так и по причине того, что часть кода закрыта от редактирования. В итоге бывает легче создать форк, чем добиться изменения функционала существующего шаблона
2.3 В случае перевода статьи из другой вики гораздо проще, особенно новичкам, работать в режиме "перевода" шаблонов - когда шаблон в ру-вики имеет то же название и те же названия полей, возникает вопрос только в переводе содержимого
2.4. Процесс унификации приводит иногда к созданию очень сложных для использования шаблонов. Допускаю, что в некоторых случаях удобнее пользоваться несколькими специализированными шаблонами. В этом отношении интересно пересмотреть кейс по "Государственный деятель 2".
3. Почему дубликаты шаблонов могут быть вредны?
3.1. Наличие одинаковых по функционалу шаблонов путает и новичков и опытных редакторов. И приводит к ненужным конфликтам ("вы использовали не тот шаблон"). Части редакторов (мне например) по большей части вопросов все равно каким шаблоном пользоваться. Оформление меня вообще слабо волнует, если это не что-то вырвиглазное. Функционал бывает критичен, но таких вопросов мало. В 99% случаев я готов пользоваться "узаконенным" типовым шаблоном. Важно чтобы этот выбор был где-то закреплен.
3.2. Большое количество разномастных шаблонов = сложность их поддержки. Чем их меньше, тем лучше, но процесс должен быть ограничен чем-то типа п.2.4
3.3. Я сторонник упорядочивания. Например карточка должна быть связана с Викиданными. При правильно организованном процессе ИМХО карточки вообще должны полностью формироваться по викиданным. Это очень отдаленное будущее, но это стоит учитывать. Тем более что по ряду тематик оно может наступить гораздо быстрее. А в процессе перехода к формированию по викиданным нам все равно придется поддерживать соответствие викиданных и значений полей в наших статьях. Это проще делать когда есть однозначная связь. Большее количество шаблонов тут мешает. (Тут правда другая проблема. Подозреваю что викиданные подстроятся под en-вики. А тогда наши карточки стоит согласовывать с карточками en-вики)
3.4. Я сторонник унификации. Разномастное оформление для меня скорее зло, чем польза. Читателям так вряд ли удобно, а мы все же для них пишем

Участник Всеслав Чародей

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

Участник putnik

1. Что вы понимаете под выражением «форк шаблона», «дубликат шаблона»?
Шаблон, который практически целиком повторяет функциональность основного, но никак с ним не связан (не наследуется от основного). Может иметь или наоборот не иметь какой-то не очень значимый для использования функционал основного шаблона или отличаться оформлением. Если ответ на вопрос «если бы данного шаблона не существовало, то можно было бы воспользоваться основным?» положительный, то это форк. Да, в такой формулировке шаблон {{Учёный}} и другие карточки для персоналий — это форк шаблона {{Персона}}, и в идеальном мире его бы могло не существовать. Но тут встаёт вопрос того, что сложнее: поддерживать много функционала в одном шаблоне или разбить его на множество. И в данном случае проще разбить на множество. Но в случае появления шаблона {{Учёный2}} ответ уже обратный — тут проще поддерживать всё в одном шаблоне.
2. Почему дубликаты шаблонов могут быть полезны?
Могут быть полезны в случаях технических ограничений для «облегчения» основного шаблона, например {{coord}} и {{coord-simple}}. Так же могут быть полезны в случае, когда при объединении всего в основной шаблон он становится неподъёмно сложным (см. пример выше про карточки). В остальном же всё, что можно объединить в один шаблон, лучше объединять.
3. Почему дубликаты шаблонов могут быть вредны?
Изменения нужно вносить в большее число шаблонов. И часто такие изменения не вносятся в часть дублирующих шаблонов, так как никто про них не помнит, в итоге со временем начинаются значимые расхождения между шаблонами. Аналогично при использовании: а) сложно выбрать правильный шаблон, б) сложно заменить один шаблон на другой (можно вспомнить расхождение в регистре и названиях параметров шаблонов-карточек до недавнего времени), в) иногда нужна функциональность нескольких шаблонов в одном месте, и за счёт несвязности кода её невозможно достичь.

Участник Helgo13

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

Участник stjn

1. Что вы понимаете под выражением «форк шаблона», «дубликат шаблона»?
Любые независимые (в плане кода или документации) шаблоны, которые повторяют основную функциональность друг друга и имеют малое число структурных (независимо от того есть ли оформительские отличия) различий.
2. Почему дубликаты шаблонов могут быть полезны?
—
3. Почему дубликаты шаблонов могут быть вредны?
Нет возможности сделать общие изменения в одном месте, нужно поддерживать в N раз больше шаблонов на одну задачу, чаще всего нарушается униформность оформления и поведения (как с шаблонами нп), из-за в целом ужасного состояния шаблонов в форках во главу ставится принцип «кто первый встал, того и тапки».

Участник Carn

1) Форк шаблона - это шаблон, который выполняет крайне сходные с данным функции, т.е. такой шаблон, который может быть в рамках правил заменён другим шаблоном и при этом будет выполнена та цель, ради которого он использовался (однако возможны различающиеся детали)
2) Дубликаты шаблонов могут быть полезны тем, что могут изменить оформление или детали поведения какого-то шаблона (установить какие-то значения по умолчанию) для какой-то группы статей, у которых эти значения всегда одинаковы и тем самым сэкономить время редакторов.
3) Дубликаты шаблонов плохи тем, что их тяжелее поддерживать (обновлять изменения из других разелов, вычищать ошибки, добавлять новые фичи и убирать устаревшие), могут возникать споры между редакторами, какой шаблон ставить, если в статье часть разделов перевёл один участник и поставил один шаблон "нп", а равную же часть другой и поставил другой шаблон "нп", то в статье будет разнобой оформления и невозможно будет решить, какой вариант следует применять.

Участник Abiyoyo

1. Форк — шаблон, выполняющий ту же функцию. Функция определяется не внешним видом (отображением), но назначением. Например, назначение шабона нп1-5 — отображать ссылку на статью в другом языковом разделе одновременно со ссылкой на отсутствующую статью в рувики. Также есть второстепенная функция отслеживания и удаления эти шаблонов по мере появления статей.
2. Дубликаты полезны для разработких новых возможностей, функций, фич. Форкование — естественный процесс разработки. Они полезны в качестве экспериментальных версий, тестируемых на ограниченном числе статей. Так проще. Особенно менее опытным участникам. Также проще доказать, что некая экспериментальная идея хороша.
3. Дубликаты вредны, если создаются для обхода консенсуса, а также в случаях, когда используются для отстаивания вкусовых пристрастий отдельных авторов, не привносят никаких новых функциональных возможностей. Пользы от этого нет, а нагрузки много. Помимо того разнобой во внешнем виде противоречит правилам и вреден с точки зрения однородности интерфейса. Запутывает, отвлекает как читателя, так и новичков. Да и старичкам лишние хлопоты. Почему консенсус плохо обходить, говорить излишне.

Волк

  1. . Это шаблон, номинально (с тем же или похожим названием) или функционально, полностью либо большей частью функционала и параметров дублирующий более ранний или более общий. Особый вид дубликата - шаблон по подмножеству объектов там где для надмножества уже есть шаблон (спортсмен/футболист).
  2. Для экспериментальных целей - попробовать (в несколько приёмов - так что предпросмотр не катит) сделать лучше (удобнее, стильнее) без риска что-то поломать или навлечь на себя гнев участников, затронутых резкими действиями. Для подмножества свой шаблон полезен, если это подмножество выделяется из надмножества более чем на 2-3 оптимум-параметра.
  3. Путаница с большим количеством плохо упорядоченных шаблонов, сложности в их обновлении и обслуживании, накопление ошибок.

Волк (обс.) 21:54, 23 ноября 2021 (UTC)[ответить]

Браунинг

Плюсы-минусы написал отдельно по каждому пункту.

Форк шаблона (или модуля, или связки шаблон+модуль) — это сложный* шаблон, код которого скопирован с кода оригинала и как-то изменён. Плюс есть в краткосрочной перспективе: форк сделать легко и быстро. Форки, действительно, неизбежны в процессе разработки. Минусы использования форков в статьях — усложнение добавления функциональности (исправив один шаблон, приходится тратить время на форк, или можно просто про него забыть). Примеры: госдеятель2 (которому не рад был никто, включая его автора) и т. д.

* — нет смысла называть форками простые шаблоны-однострочники, у которых превращение их в обёртку единого универсального шаблона приведёт лишь к усложнению. Простые шаблоны с похожим кодом можно называть членами одного семейства шаблонов. Пример: Категория:Шаблоны:Цвета.

Дубликат шаблона — это шаблон, который выполняет ту же функцию, что и оригинал, хотя названия параметров, оформление и конкретный набор фич может отличаться, а код вообще быть независимым. (Это различение между дубликатом и форком, видимо, совпадает с тем, которое провёл sas1975kr.) Пример: {{статья}}+{{книга}} vs {{публикация}}. Форк обычно является и дубликатом, но не обязательно: если кто-то возьмёт код шаблона {{Бильярдист}} и сделает из него шаблон {{Шеф-повар}}, это будет форк, но не дубликат. Наличие дубликатов даёт свободу в выборе оформления, это их плюс и минус; про это хорошо написали коллеги, особенно sas1975kr, Carn и Abiyoyo.

Обёртка шаблона — это специализированный шаблон, вызывающий другой, более универсальный шаблон (или модуль); этакое перенаправление на стероидах. Примеры: {{sub sup}} и {{sup sub}} — обёртки {{su}}, все «не переведено» — обёртки одного и того же модуля. Семейства обёрток, как и перенаправления, делают более удобным использование шаблонов; их чрезмерное многообразие может быть по-своему неудобно людям, а у самых распространённых шаблонов — и ботам. Технический минус обёрток — возможное увеличение и в итоге превышение числа включений шаблонов.

Коллеги выше отметили особый случай — поддержка популярных шаблонов из англовики сильно облегчает импорт статей, даже если это дубликаты с неконсенсусными оформлением, подлежащие исправлению. Это напомнило мне про важную проблему с шаблонами семейства WP:CS1, в первую очередь {{cite journal}}. Это как бы дубликат, но в некоторых отношениях более технически совершенный, что мешает превращению его в обёртку.

— Браунинг (обс.) 16:05, 30 ноября 2021 (UTC)[ответить]

Итог опроса Iniquity

Вопросы голоса sas1975kr Всеслав Чародей putnik Helgo13 stjn Carn Abiyoyo Волк Браунинг
1. Что вы понимаете под выражением «форк шаблона», «дубликат шаблона»?"
1.1 Форк это шаблон который дублирует другой в части выполнения основного функционала (т.е. может иметь отклонения по оформлению, и незначительные отклонения по функционалу) 8 1[ответ 1] 1[ответ 2] 1[ответ 3] 1[ответ 4] 1[ответ 5] 1[ответ 6] 1[ответ 7] 1[ответ 8]
1.2 Форк это шаблон который дублирует другой по функционалу и оформлению 1 1[ответ 9]
1.3. Дубликат - шаблон, созданный не копированием основного шаблона, а созданный независимо, но выполняющий ту же функцию 2 1[ответ 10] 1[ответ 11]
1.4. Форком не является шаблон-обертка (т.е. шаблон в котором есть вызов другого шаблона с предзаполненными параметрами), например - Ш:Книга:В.Пупкин:Трудвсейжизни и Ш:Книга 3 1[ответ 12] 1[ответ 13] 1[ответ 14]
1.5. Форком не являются шаблоны-однострочки - например ВП:ЦВЕТ. - [прим. 1] 1 1[ответ 15]
1.6. прочее 1[ответ 16] 1[ответ 17] 1[ответ 18] 1[ответ 19]
2. Почему дубликаты шаблонов могут быть полезны?
2.1. Не могут быть полезны 2 1[ответ 20] 1[ответ 21]
2.2. Дает возможность автору получить свое оформление, которое не запрещено правилами и по каким-то причинам не может быть внесено в основной шаблон. 2 1[ответ 22] 1[ответ 23]
2.3. При условии сложности внесения изменений в защищенный шаблон дает возможность создать его копию с незначительно отличающимся функционалом и/или оформлением. 1 1[ответ 24]
2.4. дает возможность легко перевести вики-текст из раздела в раздел, за счет того что имеется дубль шаблона с теми же названиями полей 2 1[ответ 25] 1[ответ 26]
2.5. Позволяет разбить один сложный для работы шаблон на несколько более простых 2 1[ответ 27] 1[ответ 28]
2.6. Позволяет получить информацию разной степени детальности (для навшаблонов) 1 1[ответ 29]
2.7. Позволяют получить более простую техническую копию основного шаблона (например {{coord}} и {{coord-simple}} ) [прим. 2] 1 1[ответ 30]
2.8. Может изменить оформление, детали поведения (предзаполенние каких-то полей) для облегчения работы с отдельными группами статей [прим. 3] 1 1[ответ 31]
2.9. Для ускорения разработки, возможностей тестирования и демонстрации нового функционала или оформления шаблона 3 1[ответ 32] 1[ответ 33] 1[ответ 34]
3. Почему дубликаты шаблонов могут быть вредны?"
3.1. Сложность выбора нужного шаблона из нескольких идентичных. И приводит к ненужным конфликтам при использовании и попытке замене на другой форк/дубль ("вы использовали не тот шаблон") 7 1[ответ 35] 1[ответ 36] 1[ответ 37] 1[ответ 38] 1[ответ 39] 1[ответ 40] 1[ответ 41]
3.2. Сложность поддержки большого количества шаблонов. Их количество нужно уменьшать, в том числе за счет запрета форков 8 1[ответ 42] 1[ответ 43] 1[ответ 44] 1[ответ 45] 1[ответ 46] 1[ответ 47] 1[ответ 48] 1[ответ 49]
3.3. Усложняет автоматизацию работы с шаблонами - ботообработку, связь с викиданными 3 1[ответ 50] 1[ответ 51] 1[ответ 52]
3.4. Делает невозможным универсальное оформление 4 1[ответ 53] 1[ответ 54] 1[ответ 55] 1[ответ 56]
3.5. Это является обходом консенсуса или нежеланием его находить 3 1[ответ 57] 1[ответ 58] 1[ответ 59]
Вопросы голоса sas1975kr Всеслав Чародей putnik Helgo13 stjn Carn Abiyoyo Волк Браунинг

Примечания

  1. ↑ разновидность обертки по п.1.4)?
  2. ↑ смутно кажется что 2.4-2.6 о чем то похожем…
  3. ↑ похоже на смесь обертки (п.1.3) и п. 2.4 и 2.6)

Ответы

  1. ↑ Шаблон, который дублирует иной в части выполнения основного функционала.
  2. ↑ Шаблон, который практически целиком повторяет функциональность основного, но никак с ним не связан (не наследуется от основного). Может иметь или наоборот не иметь какой-то не очень значимый для использования функционал основного шаблона или отличаться оформлением.
  3. ↑ 1. Форк — схожий по функционалу шаблон, который был создан с целью предоставить другое оформление или решить узкую задачу.
  4. ↑ Любые независимые (в плане кода или документации) шаблоны, которые повторяют основную функциональность друг друга и имеют малое число структурных (независимо от того есть ли оформительские отличия) различий
  5. ↑ 1) Форк шаблона - это шаблон, который выполняет крайне сходные с данным функции, т.е. такой шаблон, который может быть в рамках правил заменён другим шаблоном и при этом будет выполнена та цель, ради которого он использовался (однако возможны различающиеся детали)
  6. ↑ 1. Форк — шаблон, выполняющий ту же функцию. Функция определяется не внешним видом (отображением), но назначением. Например, назначение шабона нп1-5 — отображать ссылку на статью в другом языковом разделе одновременно со ссылкой на отсутствующую статью в рувики. Также есть второстепенная функция отслеживания и удаления эти шаблонов по мере появления статей.
  7. ↑ Это шаблон, номинально (с тем же или похожим названием) или функционально, полностью либо большей частью функционала и параметров дублирующий более ранний или более общий. Особый вид дубликата - шаблон по подмножеству объектов там где для надмножества уже есть шаблон (спортсмен/футболист).
  8. ↑ Форк шаблона (или модуля, или связки шаблон+модуль) — это сложный* шаблон, код которого скопирован с кода оригинала и как-то изменён.
  9. ↑ Форк шаблона - созданный на основании текущего шаблона другой шаблон, дающий другую функциональность или другое оформление.
  10. ↑ Дубликат шаблона - выполняющий сходную функцию, может отличаться оформлением и функционалом, а может не отличаться.
  11. ↑ Дубликат шаблона — это шаблон, который выполняет ту же функцию, что и оригинал, хотя названия параметров, оформление и конкретный набор фич может отличаться, а код вообще быть независимым. (Это различение между дубликатом и форком, видимо, совпадает с тем, которое провёл sas1975kr.) Пример: {{статья}}+{{книга}} vs {{публикация}}. Форк обычно является и дубликатом, но не обязательно: если кто-то возьмёт код шаблона {{Бильярдист}} и сделает из него шаблон {{Шеф-повар}}, это будет форк, но не дубликат.
  12. ↑ При этом к форкам/дубликатам не относятся конкретизирующие шаблоны, имеющие предзаполненные параметры (пример - Ш:Книга:В.Пупкин:Трудвсейжизни и Ш:Книга)
  13. ↑ [из ответа на п.2.] Если шаблон создан для облегчения заполнения основного, как например шаблон какой-нибудь книги, то он полезен. Но это не форк в классическом его понимании.
  14. ↑ Обёртка шаблона — это специализированный шаблон, вызывающий другой, более универсальный шаблон (или модуль); этакое перенаправление на стероидах. Примеры: {{sub sup}} и {{sup sub}} — обёртки {{su}}, все «не переведено» — обёртки одного и того же модуля.
  15. ↑ * — нет смысла называть форками простые шаблоны-однострочники, у которых превращение их в обёртку единого универсального шаблона приведёт лишь к усложнению. Простые шаблоны с похожим кодом можно называть членами одного семейства шаблонов. Пример: Категория:Шаблоны:Цвета.
  16. ↑ Сама по себе формулировка вопроса таком ключе ИМХО не очень удачна. Это накладывает ограничения на ответы п.2 и п.3. Есть процесс унификации, когда идет объединение шаблонов. Этот процесс также важен, так как является одной из причин создания форков, но мы его полезность и вредность получается не обсудим. И есть процесс связи карточек с викиданными. Оба процесса больше чем вопрос дублей шаблонов и что-то можем пустить.
  17. ↑ Если ответ на вопрос «если бы данного шаблона не существовало, то можно было бы воспользоваться основным?» положительный, то это форк. Да, в такой формулировке шаблон {{Учёный}} и другие карточки для персоналий — это форк шаблона {{Персона}}, и в идеальном мире его бы могло не существовать. Но тут встаёт вопрос того, что сложнее: поддерживать много функционала в одном шаблоне или разбить его на множество. И в данном случае проще разбить на множество. Но в случае появления шаблона {{Учёный2}} ответ уже обратный — тут проще поддерживать всё в одном шаблоне.
  18. ↑ Как правило функционал форка может быть без проблем внесён в основной шаблон, либо такой шаблон был создан из-за невозможности или нежелания достичь консенсуса по внесению изменений в основной шаблон. Последнее может рассматриваться, как нарушение режима поиска консенсуса.
  19. ↑ Семейства обёрток, как и перенаправления, делают более удобным использование шаблонов; их чрезмерное многообразие может быть по-своему неудобно людям, а у самых распространённых шаблонов — и ботам. Технический минус обёрток — возможное увеличение и в итоге превышение числа включений шаблонов.
  20. ↑ 2. Полные дубликаты шаблона, которые как бы раздваивают основной, вряд ли могут быть полезны.
  21. ↑ —
  22. ↑ 2.1 Для некоторых редакторов важно оформление именно в своем варианте. Не важно в по функционалу или оформлению. Так как я считаю шаблон всего лишь способом оформления статьи, то чтобы не демотивировать авторов я допускаю создание альтернативного оформления. Путем настроек текущего шаблона или создания дубликата, если первое не реализуемо. Есть нюанс что процесс не должен быть полностью хаотичным. Хотелось бы обоснования. Проблема в том, что под этим каждый понимает своё.
  23. ↑ Наличие дубликатов даёт свободу в выборе оформления, это их плюс и минус; про это хорошо написали коллеги, особенно sas1975kr, Carn и Abiyoyo.
  24. ↑ 2.2 Внесение в существующие шаблоны каких-либо изменений сопряжено с трудностями. Как по причине сложности нахождения консенсуса. Так и по причине того, что часть кода закрыта от редактирования. В итоге бывает легче создать форк, чем добиться изменения функционала существующего шаблона
  25. ↑ 2.3 В случае перевода статьи из другой вики гораздо проще, особенно новичкам, работать в режиме "перевода" шаблонов - когда шаблон в ру-вики имеет то же название и те же названия полей, возникает вопрос только в переводе содержимого
  26. ↑ Коллеги выше отметили особый случай — поддержка популярных шаблонов из англовики сильно облегчает импорт статей, даже если это дубликаты с неконсенсусными оформлением, подлежащие исправлению. Это напомнило мне про важную проблему с шаблонами семейства WP:CS1, в первую очередь {{cite journal}}. Это как бы дубликат, но в некоторых отношениях более технически совершенный, что мешает превращению его в обёртку.
  27. ↑ 2.4. Процесс унификации приводит иногда к созданию очень сложных для использования шаблонов. Допускаю, что в некоторых случаях удобнее пользоваться несколькими специализированными шаблонами. В этом отношении интересно пересмотреть кейс по "Государственный деятель 2".
  28. ↑ Так же могут быть полезны в случае, когда при объединении всего в основной шаблон он становится неподъёмно сложным (см. пример выше про карточки). В остальном же всё, что можно объединить в один шаблон, лучше объединять.
  29. ↑ Тут сложно сказать. В голову приходит лишь случай, когда шаблоны предоставляют информацию разной степени детальности (это больше касается навшаблонов).
  30. ↑ Могут быть полезны в случаях технических ограничений для «облегчения» основного шаблона, например {{coord}} и {{coord-simple}}.
  31. ↑ 2) Дубликаты шаблонов могут быть полезны тем, что могут изменить оформление или детали поведения какого-то шаблона (установить какие-то значения по умолчанию) для какой-то группы статей, у которых эти значения всегда одинаковы и тем самым сэкономить время редакторов.
  32. ↑ 2. Дубликаты полезны для разработки новых возможностей, функций, фич. Форкование — естественный процесс разработки. Они полезны в качестве экспериментальных версий, тестируемых на ограниченном числе статей. Так проще. Особенно менее опытным участникам. Также проще доказать, что некая экспериментальная идея хороша.
  33. ↑ Для экспериментальных целей - попробовать (в несколько приёмов - так что предпросмотр не катит) сделать лучше (удобнее, стильнее) без риска что-то поломать или навлечь на себя гнев участников, затронутых резкими действиями. Для подмножества свой шаблон полезен, если это подмножество выделяется из надмножества более чем на 2-3 оптимум-параметра.
  34. ↑ Плюс есть в краткосрочной перспективе: форк сделать легко и быстро. Форки, действительно, неизбежны в процессе разработки.
  35. ↑ 3.1. Наличие одинаковых по функционалу шаблонов путает и новичков и опытных редакторов. И приводит к ненужным конфликтам ("вы использовали не тот шаблон"). Части редакторов (мне например) по большей части вопросов все равно каким шаблоном пользоваться. Оформление меня вообще слабо волнует, если это не что-то вырвиглазное. Функционал бывает критичен, но таких вопросов мало. В 99% случаев я готов пользоваться "узаконенным" типовым шаблоном. Важно чтобы этот выбор был где-то закреплен.
  36. ↑ Возникновение войн правок (например, когда участники меняют один шаблон на другой исходя из вкусовщины)
  37. ↑ Аналогично при использовании: а) сложно выбрать правильный шаблон
  38. ↑ могут возникать споры между редакторами, какой шаблон ставить, если в статье часть разделов перевёл один участник и поставил один шаблон "нп", а равную же часть другой и поставил другой шаблон "нп"
  39. ↑ Помимо того разнобой во внешнем виде противоречит правилам и вреден с точки зрения однородности интерфейса. Запутывает, отвлекает как читателя, так и новичков. Да и старичкам лишние хлопоты.
  40. ↑ Путаница с большим количеством плохо упорядоченных шаблонов,
  41. ↑ Наличие дубликатов даёт свободу в выборе оформления, это их плюс и минус; про это хорошо написали коллеги, особенно sas1975kr, Carn и Abiyoyo.
  42. ↑ 3.2. Большое количество разномастных шаблонов = сложность их поддержки. Чем их меньше, тем лучше, но процесс должен быть ограничен чем-то типа п.2.4
  43. ↑ Сложность одновременной поддержки всего зоопарка, усложнение отслеживания.
  44. ↑ Изменения нужно вносить в большее число шаблонов. И часто такие изменения не вносятся в часть дублирующих шаблонов, так как никто про них не помнит, в итоге со временем начинаются значимые расхождения между шаблонами.
  45. ↑ 3. Форки затрудняют внесение каких-либо изменений, потому что править надо несколько. Если в шаблоне есть включения других шаблонов или модулей, которые были созданы для этого шаблона, то внесение изменений в них может сломать форк, для которого они не были предназначены.
  46. ↑ Нет возможности сделать общие изменения в одном месте, нужно поддерживать в N раз больше шаблонов на одну задачу,
  47. ↑ 3) Дубликаты шаблонов плохи тем, что их тяжелее поддерживать (обновлять изменения из других разелов, вычищать ошибки, добавлять новые фичи и убирать устаревшие),
  48. ↑ сложности в их обновлении и обслуживании, накопление ошибок.
  49. ↑ Минусы использования форков в статьях — усложнение добавления функциональности (исправив один шаблон, приходится тратить время на форк, или можно просто про него забыть). Примеры: госдеятель2 (которому не рад был никто, включая его автора) и т. д.
  50. ↑ 3.3. Я сторонник упорядочивания. Например карточка должна быть связана с Викиданными. При правильно организованном процессе ИМХО карточки вообще должны полностью формироваться по викиданным. Это очень отдаленное будущее, но это стоит учитывать. Тем более что по ряду тематик оно может наступить гораздо быстрее. А в процессе перехода к формированию по викиданным нам все равно придется поддерживать соответствие викиданных и значений полей в наших статьях. Это проще делать когда есть однозначная связь. Большее количество шаблонов тут мешает. (Тут правда другая проблема. Подозреваю что викиданные подстроятся под en-вики. А тогда наши карточки стоит согласовывать с карточками en-вики)
  51. ↑ усложнение ботообработки
  52. ↑ [Аналогично при использовании:] б) сложно заменить один шаблон на другой (можно вспомнить расхождение в регистре и названиях параметров шаблонов-
  53. ↑ 3.4. Я сторонник унификации. Разномастное оформление для меня скорее зло, чем польза. Читателям так вряд ли удобно, а мы все же для них пишем
  54. ↑ чаще всего нарушается униформность оформления и поведения (как с шаблонами нп),
  55. ↑ то в статье будет разнобой оформления и невозможно будет решить, какой вариант следует применять.
  56. ↑ Помимо того разнобой во внешнем виде противоречит правилам и вреден с точки зрения однородности интерфейса. Запутывает, отвлекает как читателя, так и новичков. Да и старичкам лишние хлопоты.
  57. ↑ Ну и главный минус форков, что это следствие нежелание нахождения консенсуса или нежелание ему следовать, а иногда и намеренное саботирование его.
  58. ↑ из-за в целом ужасного состояния шаблонов в форках во главу ставится принцип «кто первый встал, того и тапки».
  59. ↑ 3. Дубликаты вредны, если создаются для обхода консенсуса, а также в случаях, когда используются для отстаивания вкусовых пристрастий отдельных авторов, не привносят никаких новых функциональных возможностей. Пользы от этого нет, а нагрузки много. Почему консенсус плохо обходить, говорить излишне.

Кейсы по карточкам

Шаблон:Государственный деятель 2

АК:1148

Шаблон:Произведение искусства

АК:1148

Шаблон:Персонаж «Южного Парка»

АК:1181

Шаблон:Таксон/Цвет

Википедия:Заявки_на_снятие_флагов/Архив/Инженеры_и_АИ#Abiyoyo:_флаг_инженера

Кейсы по другим шаблонам

reflist+

{{reflist+}}, АК:1148

Шаблон:Comment

АК:1148

Шаблон:Соединения иода

{{Соединения иода}}, АК:1010

t:cite web 2

Ссылки на обсуждения: Project:Голосования/Допустимость оформительских форков шаблона Cite web

Кандидаты

Шаблон:Источник информации

Волчий уголок

(примеры разбора ситуации с группами шаблонов, выбранными достаточно случайным образом)

1. Шаблон {{Спортсмен}}:

  • 25 параметров, 37 подшаблонов (по отдельным видам спорта). Общая рекомендация: пользуйтесь шаблоном Спортсмен, если для нужного вида спорта не создан специализированный шаблон.
  • Примеры подшаблонов, трудно совместимые с общим (существование которых явно оправдано): баскетболист (драфты, очки, подборы, подачи, перехваты), биатлонист (гонки, точность, стойка, лёжка), горнолыжник (слалом, скоростной спуск), фигурист (партнёры, хореографы, обязательные результаты).
  • Примеры подшаблонов, легко совместимые с общим (и потенциально подпадающие под секвестр): стрелок (ничего уникального, чего не могло бы быть в статьях про других спортсменов), яхтсмен (в общем-то тоже).
  • По шаблонам бойца и гонщика (мотогонщика) идет незакрытое обсуждение на странице Википедия:К объединению/29 января 2019. Волк (обс.) 20:50, 11 декабря 2021 (UTC)[ответить]

(моё понимание возможной структуры опроса в первом приближении)

  • Вводная часть - описание текущей ситуации. В ходе работы проекта накоплено довольно много шаблонов-карточек (уточнить примерное количество), выполняющих функцию краткого резюмирования числовой и иной легко формализуемой информации об объекте статьи, расположенных на видном месте (в верхнем правом углу) и сопровождающих большую часть реально существующих статей. Вместе с тем, часть сообщества недовольна практикой создания шаблонов-дубликатов (шаблонов, дублирующих ранее существовавшие по основной части функционала, а иногда частично и по оформлению) и шаблонов-ответвлений (шаблонов, созданных на основе ранее существовавших с небольшими изменениями); распространение шаблонов - дубликатов и ответвлений осложняет их обслуживание, продуцирует конфликты на почве выбора одного из них (отличие шаблона-карточки от нижних и боковых навигационных шаблонов в том, что в статье можно использовать только одну шаблонокарточку), кроме того воспринимается частью участников как попытка обхода консенсуса и процедуры его поиска. Основные аргументы в защиту таких шаблонов связаны с определенными удобствами для отдельных авторов и их групп (сохранение элементов авторского оформления, создание шаблонов разной степени детализации, тестирование и демонстрация новой версии шаблона).
  • Вопрос 1: допустимы ли шаблоны-дубликаты и ответвления вообще?
  • варианты: да, допустимы; допустимы с ограничениями; нет, недопустимы
  • Вопрос 2: если такие шаблоны допустимы с ограничениями, какие обстоятельства могут оправдывать их создание?
  • свободный ответ (заметные отличия в желательной для резюмирования информации для подкласса статей? поэксперементировать? авторский подход? иное?)
  • Вопрос 3: если новый шаблон создаётся ввиду того, что существующий, по мнению одного или нескольких участников, недостаточно хорошо подходит для подкласса статей - нужны ли какие-то предписания и ограничения на сей счёт?
  • варианты ответов: более 2-3 желаемых новых параметров, которых нет в основном шаблоне и которые невозможно в него ввести или заменить свободным параметром? количество таких статей - от 10/20/50/100? иное?
  • Вопрос 4: если новый шаблон создаётся для целей эксперимента и демонстрации предлагаемого участником нового оформления, то какие ограничения при этом нужно ввести?
  • свободный ответ (участник должен начать дискуссию по изменению основного шаблона? этот шаблон должен как-то по-особенному называться, например, НазваниеШаблона/ДубликатНомер или НазваниеШаблона/ВерсияДата? ограничить сроки его существования, например, годом? или делать всё это только вне пространства статей, например, в личном пространстве участника)?
  • Вопрос 5: если есть шаблон для более общего класса объектов (спортсмен), то в каком случае оправдано существование отдельного шаблона для подкласса (футболист)?
  • варианты ответов: более 2-3 желаемых новых параметров, которых нет в основном шаблоне и которые невозможно в него ввести или заменить свободным параметром? количество таких статей - от 10/20/50/100? иное?
  • Вопрос 6: должны ли мы при создании и структурировании шаблонов-карточек как-то учитывать опыт крупнейших языковых разделов, из которых отдельные статьи или их содержимое по сложившейся практике заимствуются путём перевода?
  • свободный ответ
Членам рабочей группы и другим заинтересованным участникам: прошу критиковать мой проект путём размещения ответных реплик или альтернативных проектировок ниже (как это делается в обычной вики-дискуссии; не забывайте подписываться, иначе потом неудобно выискивать авторов предложений через историю правок) или в дискорд-группе; вносить изменения в мои вопросы пока не надо, это пока моё авторское видение, а не официальные проект опроса. Волк (обс.) 23:07, 3 января 2022 (UTC)[ответить]

Дополнено по замечаниям коллег:

  • Вопрос 7: нужно ли вообще регулирование шаблонокарточек правилами?
  • варианты ответов: да, нужно; нет, не нужно; да, но...; также приветствуются аргументы за и против такого регулирования.
  • Вопрос 8: нужна ли унификация кодировки шаблонокарточек по {{шаблон:карточка}}?
  • варианты ответов: да, нужна однозначно; нет, пусть каждый делает как умеет; нужна, но с условиями или ограничениями (прокомментировать); также приветствуются аргументы за и против универсальной шаблонокарточки. Волк (обс.) 21:39, 4 января 2022 (UTC)[ответить]

Видение sas1975kr

Термин форк, дубль карточки, копия карточки - вопрос скорее опроса. У каждого термина свои плюсы и минусы. Я пока буду называть "Дубль"

Есть несколько путей формирования дублей:

1) Копирование из других разделов
2) В процессе унификации создание общего шаблона, который заменяет собой несколько частных. При этом частные автоматически становятся дублями.
3) Несогласие с унификацией и создание форма под свои параметры или оформление

Т.е. вопрос дублей частный вопрос процесса унификации. Поэтому считаю что нужно смотреть более широко.

А есть ли оптимум?

С точки зрения работы с карточками для меня очевидно что недопустимы обе ситуации:

  • 1) Каждый создает карточки как хочет
  • 2) Минимальный набор карточек (в пределе одна) с максимально усложненным процедурой добавления новых параметров и изменения отображения

в 1-й ситуации минусы очевидны, перечислены в опросе Ини и это не столько проблемы дублей, сколько причины унификации и объединения карточек:

  • Зоопарк карточек тяжело поддерживать
  • При изменениях движка приводит к громадному объему работ по изменению их функционала
  • Зоопарк карточек тяжело обрабатывать ботом (сюда бы я добавил и связь с викиданными)
  • Новичкам (а иногда и старожилам) непонятно какую и когда использовать, что потенциально приводит к конфликтам

В опросе ини поднимался вопрос отображения. Но он для меня неочевиден. Скорее всего и для большинства редакторов. Т.е. вопросы:

  • 1) Унификация шрифтов, цветового оформления
  • 2) Поддержка спецрежимов - мобильной версии, визреда и устройств чтения с экрана
1-й вопрос вкусовой. Если бы я его и подымал то в режиме чего делать нельзя. И соответственно разрешено все что можно. А не пытался регламентирвоать "что можно".
2-й вопрос я бы старался учитывать, но прям делать запретом не стал бы. Все равно у каждого из этих режимов есть свои ограничения. При этом, возможно, работу по редактированию я бы не регламентировал. Но какие-то ограничения связанные с отображением бы ввел.

При этом минусы в унификации тоже есть (это мои, с ним большинство техников не согласны)

  • Объективного критерия набора параметров в карточке и его оформления не существует. По АИ его вывести невозможно. Это всегда предмет поиска консенсуса. При этом он зависит от того 1) какой набор статей рассматривается 2) кто выдвигает аргументы и подводит итог. Условно говоря при рассмотрении множества карточек "Персонажи Южного Парка" участниками проекта мультсериалы будет один. При рассмотрении всех персонажей мультфильмов условными техниками - другой. Отсюда постоянные конфликты с аргументацией "не учли мнения участников работающих с этими статьями". Stjn предложил объективный критерий - ограничение количеством статей (типа карточек на 50 статей быть не должно, их нужно объединять). Это предмет обсуждения. Он решит вопрос Южного Парка но может вылезти боком когда будут запрещены очевидно необходимые шаблоны с малым количество включений.
  • В начале моей викикарьеры под половину участников могли создавать и редактировать шаблоны и делали это. В ряде случаев это приводило к гротескным формам. Но в активных проектах (типа адмиралтейства, авиации тех же биологии, ГЕО и т.п.) шаблоны без особых проблем создавались и поддерживались самими участниками проекта. Техники привлекались по минимуму. Т.е. была масса простых шаблонов, которые поддерживались самими редакторами. Сейчас с этим проблемы. На примере того же ГосДеятель2. Объединение шаблонов приводит к созданию монстров которые тяжело редактировать и вообще их редактирование пользователю без флагов закрыто. Плюс для того чтобы их поменять приходится учитывать кучу статей со своей спецификой и искать консенсус среди большего количества участников.

Текущая ситуация

Возникающие проблемы / конфликты в процессе унификации:

  • 1) В моем понимании очевидно что один набор статей = одна карточка. При обсуждении с Завром он почему-то не поддержал. Оказалось это формально не регламентировано даже для статей, но там хоть есть консенсус что двух статей на одну тему с разными названиями быть не должно. Хотя это формально правилами не регламентировано. Но главное что никак не регламентировано что удаление дубля автоматически делает оставшуюся карточку основной, а остальные должны удаляться как дубли. Т.е. здесь бы очень помогло то о чем просил АК - правило, которое будет запрещать создание дублей "по желанию", если уже есть итог по назначению одной из карточек основной. В таком варианте ГосДеятель2 просто бы не создали. И тогда пришлось бы оспаривать/пересматривать итог по ГосДеятель.
  • 2) Неоптимальность процедур и сложность поиска консенсуса даже в очевидных случаях. На примере того же ГосДеятель2. При недостаточной аргументации ошибочно параметр Порядковый номер был удален. При этом вернуть его оказалось сложнее, чем создать дубль.
  • 3) Неготовность к компромиссам и способность прийти к консенсусу. Беда сообщества. Накопленные конфликты в том числе между собой приводят к неготовности идти на компромиссы и искать устраивающие большинство решения. В половине случаев предварительное обсуждение в режиме мозгового штурма, уважение к собеседникам и готовность услышать другую сторону позволили бы решить вопрос. Но обсуждение часто сказывается в срач и обсуждение вроде бы очевидного и несложного вопроса приходит в тупик, потому что обе стороны закусили удила.
  • 4) Частенько неготовность авторов учитывать мнение техников, вплоть до игнорирования кривого отображения в мобильной версии и т.п. Потому что в стационарной версии его всё устраивает, а правил запрещающих ему так делать нет.

Цель опроса

Если грубо - в 90% случаев к работе Завра по объединению вопросов нет. Это либо очевидные вопросы, либо не поддерживаемые шаблоны. Хотелось чтобы такую работу мы если не упростили, то как минимум не усложнили. Есть 10% когда могут или возникают конфликты. Там где часто обсуждение скатывается в срач. И происходит демотивация что редакторов, что техников. В идеале задача как-то уменьшить эти конфликты. При этом не хотелось чтобы работа по объединению превращалась в сизифов труд. Т.е. та самая борьба с дублями. Если решили использовать какую-то карточку, то ее регламентировать как основную. И запретить дубли.

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

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

Технические меры

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

1) Добавляем в каждую карточку возможность выводить произвольное свойство с произвольным названием. Т.е. в карточке "Персонаж мультсериала" добавляем "произвольная метка 1" "Произвольный текст 1". И делаем либо шаблон обертку "Персонаж Южного Парка" либо прямой вызов с допсвойств "цвет волос":"синий". Минус что обрабатывать такое потом ботом нереально.
2) Упрощаем возможность создания мастер-шаблонов. Типа "Персонаж" с произвольным набором параметров, включая волосы. И разрешаем пользователям создавать произвольные шаблоны обертки на его основе - "Персонаж мультсериала", "Персонаж Южного парка". Можно даже разрешить менять выводимое название реквизита, главное что при этом остается связь с мастер-шаблоном.
3) Где-то храним набор параметров. В идеале на викиданных. Но с учетом сложности их добавления туда, возможно что-то внутрипроектное. При этом в карточке обязуем связать поле с набором параметров. Это сделает элементарной обработку ботами, при наличии связей с шаблоном из другого раздела позволит сделать автозамену перетянутого, облегчит связь с викиданными и т.п. Например совместив с п.1 позволит добавлять реквизиты которые потом можно обрабатывать ботом. Это позволит облегчить работу по замене одного шаблона другой при подведение итога об объединении. Сделает более объективным аргументы об объединении, усложнит создание дубля.
4) Если развить п.3 то в теории работу Завра можно разбить на две. Технически оставлять тоже оформление с переводом на карточку и связями с набором параметров. И запускать обсуждение, в котором не участвовать. Придут к итогу объединить - запуском бота все сводится к одному шаблону. Не придут - не велика беда. Останутся связи и универсальные процедуры.
5) В теории карточка это просто набор выводимых заголовков, названий параметров и самих параметров. Т.е. можно создать мастер-шаблон (по логике это {{карточка}} и есть. Но может что-то более простое). И даем пользователям создавать карточки самостоятельно. Главное чтобы было обязательное использование мастер-шаблона и параметры по п.3 были связаны с универсальным набором параметров. Это переложит нагрузку по сопровождению на редакторов. При этом оставит возможность быстрой ботозамены в случае принятия решения о удалении/объединении шаблона.
6) Это не столько к карточкам, сколько вообще к шаблонам. Возможность скармливать строку движку форматной строки вида {{Параметр1.}}&","+&{{Параметр1}}<sup>{{Параметр2}}</sup>. Где {{Параметр1|. }} - если параметр1 передан, выводим его и после него точку с пробелом. В теории если заложить туда курсив, цвет и т.п. то можно свести например шаблоны источников к одному шаблону с передачей в него форматной строки. Это же можно скармливать карточке, получая произвольное оформление в рамках одного механизма.
7) Можно ли сделать отображение одного шаблона разным в разных режимах. Например в мобильной версии выводить по одному (с обрезанными цветами например) и стационарной по другому. По настройке в своем джава скрипте, или вообще по умолчанию. Например в мобильной версии всегда выводить шаблон по другому. Я в свое время задавал этот вопрос Джеку по примечаниям, он не исключил такой возможности

Регламентация

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

  • Аби свято уверен что все против дублей и за единое оформление. Я конечно уверен что не все, но вдруг Завру улыбнется счастье. Как-то нужно составить вопрос(ы) которые выяснят так ли это.
  • Какое-то правило которое поможет узаконить итог по удалению карточек как итог по назначению одной карточки основной и автоматически назначением остальных дублями. Либо в рамках текущего ВП:КУ. Либо (что мне больше нравиться) в рамках отдельной площадки. Условная площадка с 2-х недельным обсуждением по логике не дала бы просто так удалить параметр в госдеятеле2, а во вторых не дало бы без обсуждения создать дубль.
  • Какие-то меры по увеличению заинтересованных участников. По логике это оповещения, но тут надо думать как. Оповещать всех на канале все забраковали. Но я бы подумал. Минусы понятны. Риск заболтать итог. Голоса "ваше оповещение отвлекает меня от работы". Но и плюсы есть. Это во первых позволит рассмотреть большее количество аргументов, а во вторых уберет аргументы оспаривания итога "нас не позвали, наши аргументы не учтены".
  • Рассмотрел бы вариант назначения троек для подведения итога. Это во-первых позволит разделить ответственность, во-вторых повысит доверие к итогу, в третьих (в теории) позволит упростить его подведение. Повторюсь что объективных критериев во многих случаях нет. Поэтому условное голосование трех опытных участников
  • Задал бы вопросы сообществу, которые можно включить в правило в режиме "разрешено/запрещено". Типа того вопросов когда дубли допустимы и вопрос Йохана можно ли создавать дубль для 50 карточек.
  • попробовал бы регламентировать понятие дубля. Но тут соглашусь с завром, рискуем ни к чему не прийти.

Оформление

Вопрос вкусовой. Поэтому просто попытался бы понять есть ли у сообщества хоть какое-то общее видение.

  • Нужно ли добиваться единого оформления или должна быть свобода в рамках правил проекта (что не запрещено то можно)
  • Можно ли частным проектам приходить к локальному оформлению (цвет стен архива ЕМНИП как называл это Йохан) - цвет таксонов и т.п. или это должна быть прерогатива .
  • Нужно ли правило(а) которое будет регламентировать необходимость отображения в спецрежимах. или рекомендации. или вообще не учитывать

Атмосфера

Вообще не тема опроса. Но вдруг кто-то что-то дельное предложит. Спросил бы у сообщества как они себе видят возможность снижения межличностных конфликтов. Меня убивает фраза "инженеры окопались в крепости". Хотелось бы как-то показать что весь мир против них не воюет. Что их труд тоже ценят. Просто в википедии, к сожалению, времена сейчас такие. У каждого свои тараканы и не у всех они ручные. Как варианты:

  • Викивстречи или видеоконференции, возможно просто разговоры 1 на 1 (тяжелее посылать на человека, с которым общался. Да и разговор потом идет зачастую в другом ключе, понимая мотивацию другого человека). Даже интересно что про меня Завр думал до работы по карточкам и сейчас. Интересно поменялось ли что-то.
  • Совместная работа. Найти фронты работ по которым требуются объединенные усилия.
  • Посредники. Сомневаюсь что такие альтруисты найдутся. Но вдруг. Возможно привлечение в споры сторонних участников, в идеале знакомых между собой, позволит проще приходить к компромиссам. В какой-то мере это вопрос "троек" по подведению итогов.

Черновик опроса

Общие принципы

  • ИМХО суть опроса должна быть в виде - фиксируем проблему (т.е. что не устраивает в текущем состоянии. Пытаемся понять к какому состоянию хотим прийти. И какими инструментами это можно сделать.
  • идем по принципу - определяемся с разделами, в каждом разделе определяемся с набором вопросов. Рассматривал бы как предварительный конструктор. Т.е. не фиксируем пока жесткую структуру разделов и набрасываем возможные разделы и вопросы. Пусть даже они в некоторых разделах пока будут совпадать. Потом перекомпонуем объединив / удалив какие то разделы/ вопросы.
  • все это в режиме мозгового штурма. Не заморачиваемся пока с формулировка и консенсусом. Потом можно будет обсудить или проголосовать что оставлять и какие формулировки использовать. Главное чтобы была понятна идея.

Выясняем мнение сообщества. Типа "Согласны ли в следующими утверждениями"

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

вопросы которые призваны ответить на то что такое форк/дубликат/аналог

(если получится - выведем формулу что такое форк/аналог. В любом случае узнаем у сообщества что они считаю допустимым а что нет. Поэтому вопросы формируем в режиме что можно что нельзя)

  • наличие нескольких шаблонов для почти идентичной функции (например Книга / Публикация или НП1-НП5) приводит к путанице авторов, особенно новичков, которые не могут определиться какой шаблон им выбрать. И приводит к ненужным конфликтам из-за споров какой из шаблонов должен быть в статье
  • допустимо наличие более одного шаблона для сходной функции если они дают разное оформление, которые не запрещены другими правилами Википедии (Непереведено1...Непереведено5)
  • наличие шаблона-аналога выполняющего сходную функцию, даже в том случае если оно дает другое оформление, в общем случае недопустимо (возможные исключения ниже)
    • допустимо создать временный шаблон-аналог (особенно при большом количестве включений или защищенном шаблоне) с целью демонстрациями предлагаемых изменений
    • не является шаблоном-аналогом шаблон с некоторыми предзаполненными данными (примеры - оформление источников в виде Ш:Книга:В.Пупкин:Трудвсейжизни и Ш:Книга)
    • шаблоном-аналогом не являются шаблоны-однострочки - например ВП:ЦВЕТ
    • создание шаблона-аналога, с названиями полей совпадающими с шаблонами в другом разделе позволяет более просто переводить статью из одного раздела в другой)
      • варианты - связка с шаблоном из нашего раздела с ботозаменой? Или просто превращение его в обертку над нашим шаблоном
    • иногда имеет смысл сделать более технически простой аналог (пример {{coord}} и {{coord-simple}})
    • создание шаблонов-оберток позволяет упростить использование и не является шаблонами-аналогами (например {{sub sup}} и {{sup sub}} — обёртки {{su}})

=== попытаться выяснить какие проблемы связанные с шаблонами видит сообщество (это если делать отдельный опрос по карточкам - выясняем проблематику)

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


общие проблемы для чего нужна унификация и какие проблемы с ней связаны

(думаю все понимают что унификация нужна. Вопрос только нужно ли ее ограничивать)

  • большое количество шаблонов сложно поддерживать. Их количество нужно уменьшать в том числе путем унификации (объединения)
  • большое количество несвязанных шаблонов и их параметров затрудняет ботообработку
    • унификация имеет свои пределы. Она может приводить к созданию шаблонов со сложностями и поддержки и при использовании (пример - шаблон {{Госдеятель}})
    • нужно вводить запрет на создание шаблонов-аналогов. Это позволит в том числе снизить трудоемкость техподдержки за счет уменьшения количества шаблонов
    • иногда имеет смысл разбить один сложный шаблон на несколько более простых.
      • если такая ситуация возникает, следует стремиться создавать шаблоны-обертки?

вопросы связанные по унифицированному оформлению

(пытаемся понять настроение сообщества на тему оформления. Может действительно проблемы нет и есть консенсус за единый стандарт оформления)

  • жизнь разнообразна, привести все к единому стандарту невозможно - пускай цветут сто цветов
  • следует стремиться к единым стандартам оформления, но это должно определяться правилами википедии. Что не запрещено, то разрешено. Шаблоны не должны влиять на оформительские вопросы. Для единого оформление следует принять правило по единому оформлению. Если такое правило невозможно принять, значит это вкусовой вопрос и его нет смысла регламентировать.
  • для людей хотящих единое оформление следует сделать настройки, которые для всех будут отражать текущее многообразие, а для них - унифицированный вариант (срачный момент. Может действительно стоит обсудить варианты. Тот же вариант ГОСТА это теоретически решает)
  • следует стремиться к единым стандартам оформления, следует ограничить варианты оформления и реализовать их в соответствующих шаблонах (т.е. фиксируем текущий бардак и не даем создавать новый. Пытаясь разгребать то что есть)
  • следует как минимум в шаблонах прийти к единому оформлению. Разрешив ручное оформление по другим вариантам.
  • следует прийти к единому оформлению. Решение оформительских вопросов заблокировано. Поэтому следует по каждому основному шаблону (не переведено, Книга и т.п.) прийти к единому оформлению и зафиксировать их в шаблонах, запретив другое оформление.

процесс унификации может приводить к конфликтам. Можно ли их уменьшить?

(если унификация неизбежна, попытаемся выяснить как снизить конфликты которые возникают при ее реализации)

  • ВП:НЕПЛОМАНО - конфликты неизбежны, всем неугодишь. Текущих правил инструментов достаточно,
  • не хватает правил по работе с шаблонами, их следует создать что-бы уменьшить количество конфликтов. Примеры правил:
    • регламентировать что является шаблоном-аналогом. Итоги на КУ по удалению подводить назначением основного шаблона. Автоматически считать что все создаваемые шаблоны-аналоги должны выставляться на удаление (КБУ?).
    • создать отдельную площадку для обсуждения шаблонов. Это позволит не просто подводить итог по удалению, но и считать его итогом фиксирующим консенсус по назначению основного шаблона
    • есть проблема с недостаточным количеством участников. Нужно придумать систему оповещений (тут можно сразу предложить варианты к обсуждению)
    • есть проблема с недоверием к итогу по шаблонам. В сложных случаях следует итог подводить итогом нескольких опытных участников. Это позволит распределить ответственность, снизить давление на одного подводящего итог и учесть большее количество мнений. За основу можно взять режим ВП:ТАК или просто сразу назначать из ПУЛа опытных участников (один админ, один техник, один экзопедист).

вопросы карточек

  • 1. ВП:НЕПОЛМАНО - типа итак работает, ничего не меняем
  • 2. я против карточек вообще, давайте их удалим и проблемы не будет
  • 3. (варианты правил из унификации выше - уведомления, площадки, ВП:ТАК)
  • 4. Очевидно что нельзя создать одну карточку. И нет смысла иметь отдельную карточку на несколько статей. Но при этом нет объективных критериев оформления карточки и набора ее полей. Пример с Как можно регламентировать этот процесс?
    • 4.1. Оговариваем диапазон, ниже которого карточки в любом случае объединяются (меньше 50?), выше которого можно не объединять просто если кто-то будет против, даже при слабой мотивации (свыше 1000 включений), внутри диапазона - ищем консенсус
    • 4.2. Просто связываем шаблоны с викиданными, рано или поздно мы все равно перейдем на отображение карточек по викиданным
    • 4.3. При создании нового шаблона обязываем создать карту связей (либо с параметрами текущих шаблонов, либо с неким набором полей (в теории свойств викиданных). Это упростит ботообработку, позволит легко конвертировать или делать обертки для шаблонов из других разделов, уменьшит произвол при создании новых шаблонов и упростит при необходимости замену на базовый шаблон и т.п.).
  • 5. Технические средства уменьшения нагрузки на техников (провокация. Стоит сначала обсудить с техниками и возможность и целесообразность)
    • 5.1) Упрощаем возможность создания общего шаблона (т.е. делаем Базовый Персонажа мультфильма. В котором добавляем параметр волосы.
    • 5.2) формально все шаблоны одинаковы - раздел, параметр, значение, ссылка на викиданные. Стиль раздела, стиль заголовка, стиль текста. Возможно можно создать некий базовый шаблон / набор шаблонов, которые позволят пользователю с минимальным технавыками создавать карточки (в теории это Карточка, но может еще упростить). Тогда поддержка нужна будет только для базового шаблона. А сами карточки легко и редакторы смогут редактировать/ менять. И тогда пусть сами договариваются как оформлять шаблон. Это уберет необходимость техникам влазить в зубодробильные согласования, которые и вызывают основные конфликты и занимают у них по идее под 90% времени. Если как-то ограничить названия полей (см. п. 4.3) тогда даже если в с карточкой накуролесят, легко будет ботозаменой заменить весь этот зоопарк на что-то базовое. Да и спецрежиме в таком случае проще сделать. И библиотеку стилей можно подключить, которые в будущем при победе адептов серого цвета заменить на что-то унифицированное...

вопросы связанные с спецрежимами чтения и редактирования (стационарная/мобильная версии, просмотр статей с устройств для чтения с экрана)

Выясняем что сообщество думает по этому поводу

  • я все равно буду поступать как хочу
  • у спецрежимов в любом случае есть физические ограничения не совместимые с отображением в стационарной версии. Поэтому нужно ограничиться универсального отображения только для преамбулы и/или спецсредств типа {{аудиостатья введение}}
    • у спецрежимов в любом случае есть физические ограничения не совместимые с отображением в стационарной версии, следует оставить стационарную версию как есть, и добиваться технических способов реализации отдельных спецрежимов (провокационный вопрос. Возможно просто стоит просто сразу с техниками обсудить возможность вариантов):
      • делать для шаблонов различное поведение в стационарной и мобильной версии (по reflist Джек ЕМНИП намекал что это возможно, но по каким-то причинам он был не готов это сделать)
      • возможности спецрежимов по скриптам пользователя (например при включенном спецрежиме "устройство чтения с экрана" выводить все НП1...НП5 в спецвиде)
    • следует рекомендовать чтобы оформление позволяло и редактировать и отображать вики-текст во всех режимах. Эти рекомендации должны быть закреплены в виде эссе или руководства.
    • следует добиваться того чтобы оформление позволяло и редактировать и отображать вики-текст во всех режимах.

Вариант Всеслава

Вступление

Вопрос разработки и использования так называемых шаблонов-дубликатов периодически ставится перед сообществом. В ходе рассмотрения заявки № 1181 Арбитражный комитет постановил провести опрос участников Википедии

Терминология

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

Функционал шаблона — основное выполняемое им действие. По своим функционалам шаблоны могут быть сгруппированы в несколько множеств.

Основной массив составляют следующие группы:

  1. шаблоны-карточки (Ш:Учёный, Ш:Футболист, Ш:Река и т.п.);
  2. навигационные шаблоны (Ш:Города Свердловской области, Ш:Короли Англии и т.п.);
  3. шаблоны-источники (как общие — публикация, книга, статья, cite web и т. д., так и частные — БСЭ, ГИ, ГВР, словари и т. д.);
  4. оформительские шаблоны (типа ВД-Преамбула, цитата, графики, таблицы, ПозКарта и т. д.);
  5. «технические» шаблоны (nobr, ударение, lang-x, шаблоны внутри шаблонов и т. д.);
  6. шаблоны, облегчающие использование общих для группы статей фрагментов текста (общий абзац нескольких статей, заполненная футбольная таблица в статье о сезоне команды, иные таблицы, вынесенные на подстраницы и т. д.);
  7. шаблоны-украшения (мячики и стрелочки в футбольных статьях, шаблоны-таблички автодорог, стаб-шаблоны и т. д.);
  8. информационно-служебные шаблоны (нет ссылок, нет сносок, статусные звёздочки, предупреждения, проектные шаблоны на СО и т. д.);
  9. тестовые.

Основные функции этих групп шаблонов — следующие:

  1. карточки: предоставление в сжатом, компактном виде сведений о предмете статьи;
  2. навигационные шаблоны: предоставление возможности быстрой навигации между группой статей, объединённых общей темой;
  3. источники: форматный вывод ссылки на источник и/или библиографических данных источника;
  4. оформительские: вывод фрагмента текста, оформленного или структурированного согласно правилам или консенсусу участников, либо в графическом виде;
  5. «технические»: упрощение использования функций викидвижка, эмуляция отсутствующих функций парсера;
  6. «облегчающие»: упрощение использования общих для группы статей фрагментов текста;
  7. украшения: шаблоны, не несущие в себе иных функций, кроме эстетических (в понимании создателя);
  8. информационно-служебные: сигнализация о недостатках, достоинствах статьи, предупреждение участников о чём-либо; в общем, шаблоны, не связанные ни с темой статьи, ни с контентом, а предназначенные для авторов и характеризующие текущее состояние статьи;
  9. тестовые: могут относиться к любой из вышеперечисленных групп, однако являются временными и предназначены для тестирования вносимых изменений или демонстрации предлагаемых изменений или функций.

Любой шаблон, относящийся к одной из перечисленных выше групп, по отношению к другим шаблонам этой группы может оказаться относящимся к одному из трёх типов (шаблоны, заметно отличающиеся от него, разумеется, тут не рассматриваются) (ПРИМ: термин «форк» не использован сознательно — в ходе обсуждения выяснилось разное понимание — как копии (по аналогии с db-fork), как отдельной ветви (как в программировании) и т. д. — В.Ч.):

а) шаблон-дубликат: шаблон, имеющий тот же функционал, что и исходный, и отличающийся от него отдельными неключевыми элементами (например, дополнительная графа в карточке, не являющаяся ключевой характеристикой предмета статьи), оформлением (не относится к шаблонам, функционалом которого является именно оформление) и т. д. Может возникать как при копировании исходного шаблона, так и просто при независимом создании шаблонов. А также при объединени карточек например "Персонаж сериала" автоматически все карточки "Персонаж ХХХ" становятся дулями.
б) шаблон-ответвление (ПРИМ: лучше сказать обёртка? — В.Ч.): шаблон, конкретизирующий более общий (Ш:Учёный по отношению к Ш:Персона; шаблоны-ссылки на конкретные источники по отношению к Ш:Публикация).
в) шаблон-аналог: шаблон, совпадающий по функционалу с исходным, но предназначенный для применения в иной области (Ш:Баскетболист по отношению к Ш:Футболист).

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

Обоснование необходимости опроса

Требования к статьям и их жизненный цикл в Википедии регулируются правилами. При их нарушении существование статей-форков признаётся нецелесообразным и они подлежат удалению. В пространстве шаблонов такая регламентация отсутствует. Правил оговаривающих процесс унификации, признания шаблонов форками и работы с ними не существует. Это приводит к следующим проблемам:

  1. усложнение контроля и технической поддержки ввиду увеличения количества шаблонов, за которыми надо следить;
  2. захламление пространства шаблонов;
  3. увеличение входного порога Википедии для новичков — им приходится разбираться, какой шаблон нужно использовать, а какой просто лежит с незапамятных времён.
  4. трудности с подведением итогов об удалении/оставлении шаблона — автор итога вынужден ориентироваться не на правила, а на собственное понимание — а это приводит к долгим дискуссиям, оспариваниям итогов в разных инстанциях вплоть до АК (941, 1085, 1087, 1116, 1122, 1148 да и просто увеличивает срок существования номинации — администраторы и ПИ не хотят связываться с потенциальной тягомотиной;
  5. повышение затрат времени и труда на создание и поддержание технической документации (шаблонам требуется документация, желательно машиночитаемая (TemplateData) — без неё, например, карточки при заполнении через визуальный редактор пишутся в одну строчку; да и в целом отсутствие документации усложняет использование шаблонов).

Регламентирующее удаление шаблонов решение по иску № 1010 признано неудачным, а решение по иску № 1087 описывает лишь один частный вопрос. В связи с этим и основываясь на решении АК, рабочая группа выносит на рассмотрение участников ряд вопросов и предложений.

Опрос

1 Блок общих вопросов

1.1 Нужно ли регулирование создания и/или применения шаблонов?

Возможные ответы: да/нет

1.2 Нужно ли удалять неиспользуемые (=ненужные) в течение долгого времени шаблоны?

Возможные ответы: да/нет
1.2.1 Каким должен быть минимальный срок существования шаблона без включений, чтобы он подлежал удалению по причине неиспользуемости?
Возможные ответы: месяц/полгода/год/иное

1.3 Нужно ли нам правило, регламентирующее удаление шаблонов?

Возможные ответы: да/нет
1.3.1 Если да, то что бы Вы хотели видеть в правиле?
Возможные ответы: в свободной форме

1.4 Поддерживаете ли Вы унификацию шаблонов при возможности её проведения без изменения (или с незначительным изменением) функционала?

Возможные ответы: да/нет

1.5 При каком количестве планируемых включений разумно создавать новый шаблон?

Возможные варианты ответов: 5/10/25/50/100/более/не регламентировать/иное

1.6 Считаете ли вы необходимым создание новой площадки для обсуждения вопросов по объединению и удалению шаблонов по примеру ВП:ОБКАТ, en:Wikipedia:Templates for discussion, или достаточно существующей ВП:КУ?

Возможные варианты ответов: не нужна, нужна потому что…

1.7 Нужны ли дополнительные меры по уведомлению участников об обсуждении удаления / объединения шаблона. Если нужны, то какие по вашему?

Возможные варианты ответов: не нужны; нужны, в варианте en:Wikipedia:Templates for discussion, шаблон по типу КУ, уведомление проектов по типу уведомления КУ и КМП от нирвана бот, по списку проектов которые записались на подстранице шаблона, свои варианты…

1.8 Нужно ли регламентировать в правилах отображения в шаблонах в спецрежимах (поддержка визред, мобильная версия, поддержка устройств чтения с экрана)

Возможные варианты ответов: жестко регламентировать, рекомендовать, не учитывать.

2 Блок частных вопросов

2.1 Шаблоны-дубликаты

(ПРИМ: это самый важный вопрос, тут пункты надо продумать — В.Ч.)

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

2.1.1 Какие шаблоны считать дубликатами?
а) имеющие один функционал, но разное оформление (если функционалом не является оформление);
Возможные ответы: да/нет
б) отличающиеся малым (1-3) количеством второстепенных (ненужных для значительного массива статей) параметров;
Возможные ответы: да/нет
в) отличающиеся заметным (более 3) количеством второстепенных параметров;
Возможные ответы: да/нет
г) отличающиеся малым (1-3) количеством ключевых параметров;
Возможные ответы: да/нет
д) иное.
Возможные ответы: в свободной форме
2.1.2 Допустимо ли создание и использование шаблонов-дубликатов?
Возможные ответы: да/с ограничениями/нет/иное
2.1.2.1 Если создавать будет допустимо с ограничениями, то какие ограничения следует предъявлять к создаваемым дубликатам?
а) количественные — создание допустимо начиная с некоторого предполагаемого количества включений;
Возможные ответы: да (+граничное количество)/нет
б) функциональные — начиная с некоторого количества параметров, отличающих дубликат от исходного шаблона;
Возможные ответы: да (+граничное количество)/нет
в) хронологические — только на период времени, не превышающий T0;
Возможные ответы: да (+желательное значение T0)/нет
г) иные ограничения.
Возможные ответы: в свободной форме
2.1.3 Допустимо ли создание дубликатов, отличающихся от исходного шаблона лишь оформлением (если именно оформление не является основным функционалом шаблона)?
Возможные ответы: да/нет/иное
2.1.4 Следует ли участнику, желающему создать дубликат, сначала попробовать внести недостающий функционал в исходный шаблон, а при несогласии других участников — искать консенсуса на СО шаблона, на форумах и т. д. прежде, чем создавать дубликат?
Возможные ответы: да/нет/иное
2.1.5 Следует ли удалять дубликаты, создание которых было обусловлено не объективными причинами, а личными предпочтениями автора и автор не смог привести веских логических доводов в пользу существования шаблона?
Возможные ответы: да/нет/удалять с отсрочкой
2.1.6 Как назвать эту сущность? Какие шаблоны считать дубликатами?
а) дубль
б) форк
в) копия
г) свой вариант
2.2 Шаблоны-аналоги

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

2.2.1 Поддерживаете ли Вы создание общих шаблонов?
Возможные ответы: да/нет
2.2.2 При каком количестве частных шаблонов стоит создавать общий?
Возможные ответы: 2/3/более 3/иное
2.3 Шаблоны-ответвления

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

2.3.1 Поддерживаете ли Вы регулирование создания шаблонов-ответвлений?
Возможные ответы: да/нет
2.3.2 При каких из перечисленных ниже условий допустимо создание шаблонов-ответвлений?
а) Когда количество параметров, могущих быть предзаполненными (общих для группы статей), превышает количество параметров, нуждающихся в индивидуальном заполнении (пример — шаблоны-источники: библиографическое описание заполняется единожды и в шаблоне, а в статьях проставляются только страницы и названия разделов);
Возможные ответы: да/нет/иное
б) Когда для группы статей существует строго определённое множество параметров, являющееся подмножеством множества параметров общего шаблона (пример — различные ответвления шаблона «карточка»);
Возможные ответы: да/нет/иное
в) свой вариант ответа, свои предложения
Возможные ответы: в свободной форме
г) Ясно, что подмножество параметров из п. б) должно быть заметно меньше множества параметров общего шаблона, потому как иначе проще использовать общий. Однако, стоит провести ориентировочную границу отношения их величин при которой создание шаблона-ответвления признаётся допустимым. Какой вариант поддерживаете?
Возможные варианты: 1/3, 1/2, 2/3, 3/4, иное
2.4 Отдельные группы шаблонов

Здесь рассматриваются вопросы, касающиеся отдельных групп шаблонов и не относящиеся к шаблонам в целом.

2.4.1 Тестовые шаблоны

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

2.4.1.1 Нужно ли регламентировать создание/использование тестовых шаблонов?
Возможные ответы: да/нет
2.4.1.2 Поддерживаете ли следующую схему работы с тестовыми шаблонами:
а) тестовый, экспериментальный, демонстрационный шаблон должен содержать указание на свою экспериментальность. Это может быть его создание в Песочнице или на подстранице основного шаблона, соответствующая надпись на странице шаблона или в его коде и т. д.;
б) после потери актуальности экспериментальный шаблон должен быть удалён;
в) запрещаются массовая простановка экспериментальных шаблонов в основном пространстве, а также их использование в ОП иначе, чем с демонстрационными целями либо целями тестирования (в случае невозможности тестирования в специально предназначенных для этого местах)?
Возможные ответы: да/нет/иное
2.4.2 Шаблоны-украшения

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

2.4.2.1 Нужно ли регламентировать создание/использование шаблонов-украшений?
Возможные ответы: да/нет
2.4.2.2 Что нужно для создания/применения таких шаблонов?
Возможные ответы:
а) желание автора шаблона;
б) консенсус группы участников (проекта), активно правящих статьи, относящиеся к области знаний, в которой планируется применение шаблона;
в) общевикипедийный консенсус;
г) иное.


Вариант Всеслава с сокращениями

Вступление

Вопрос разработки и использования так называемых шаблонов-дубликатов периодически ставится перед сообществом. В ходе рассмотрения заявки № 1181 Арбитражный комитет постановил провести опрос участников Википедии

Терминология

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

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

а) шаблон-дубликат (синонимы - копия, форк) - шаблон, имеющий тот же функционал, что и исходный, и отличающийся от него отдельными неключевыми элементами (например, дополнительная графа в карточке, не являющаяся ключевой характеристикой предмета статьи), оформлением (не относится к шаблонам, функционалом которого является именно оформление) и т. д. Может возникать как при копировании исходного шаблона, так и просто при независимом создании шаблонов.
б) шаблон-обёртка - специализированный шаблон, вызывающий другой, более универсальный шаблон. С целью заполнить некоторые параметры шаблона или упростить работу с его настройкой. Например шаблоны-ссылки на конкретные источники по отношению к {{Книга}} - {{Книга:Патянин - Бисмарк и Тирпиц 2014}} и {{Книга:Staff_German_Battlecruisers}} позволяют заполнить большинство полей в шаблоне {{Книга}}. А шаблоны {{sub sup}} и {{sup sub}} — обёртки {{su}}, позволяющие упросить его вызов.

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

Обоснование необходимости опроса

Требования к статьям и их жизненный цикл в Википедии регулируются правилами. При их нарушении существование статей признаётся нецелесообразным и они подлежат удалению. В пространстве шаблонов такая регламентация отсутствует. Это приводит к следующим проблемам:

  1. усложнение контроля и технической поддержки ввиду увеличения количества шаблонов, за которыми надо следить;
  2. захламление пространства шаблонов;
  3. увеличение входного порога Википедии для новичков — им приходится разбираться, какой шаблон нужно использовать, а какой просто лежит с незапамятных времён.
  4. трудности с подведением итогов об удалении/оставлении шаблона — автор итога вынужден ориентироваться не на правила, а на собственное понимание — а это приводит к долгим дискуссиям, оспариваниям итогов в разных инстанциях вплоть до АК (заявки АК:941, АК:1010, АК:1085, АК:1087, АК:1116, АК:1122, АК:1148, АК:1181 да и просто увеличивает срок существования номинации — администраторы и ПИ не хотят связываться с потенциальной тягомотиной;
  5. повышение затрат времени и труда на создание и поддержание технической документации (шаблонам требуется документация, желательно машиночитаемая (TemplateData) — без неё, например, карточки при заполнении через визуальный редактор пишутся в одну строчку; да и в целом отсутствие документации усложняет использование шаблонов).

Регламентирующее удаление шаблонов решение по иску № 1010 признано неудачным, а решение по иску № 1087 описывает лишь один частный вопрос. В связи с этим и основываясь на решении АК, рабочая группа выносит на рассмотрение участников ряд вопросов и предложений.

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

Опрос

1 Блок общих вопросов

1.1 Нужно ли регулирование создания и/или применения шаблонов?

Возможные ответы: да/нет

1.2 Нужно ли удалять неиспользуемые (=ненужные) в течение долгого времени шаблоны?

Возможные ответы: да/нет
1.2.1 Каким должен быть минимальный срок существования шаблона без включений, чтобы он подлежал удалению по причине неиспользуемости?
Возможные ответы: месяц/полгода/год/иное

1.3 Нужно ли нам правило, регламентирующее удаление шаблонов?

Возможные ответы: да/нет
1.3.1 Если да, то что бы Вы хотели видеть в правиле?
Возможные ответы: в свободной форме

1.4 Поддерживаете ли Вы унификацию шаблонов при возможности её проведения без изменения (или с незначительным изменением) функционала?

Возможные ответы: да/нет

1.5 При каком количестве планируемых включений разумно создавать новый шаблон?

Возможные варианты ответов: 5/10/25/50/100/более/не регламентировать/иное

1.6 Считаете ли вы необходимым создание новой площадки для обсуждения вопросов по объединению и удалению шаблонов по примеру ВП:ОБКАТ, en:Wikipedia:Templates for discussion, или достаточно существующей ВП:КУ?

Возможные варианты ответов: не нужна, нужна потому что…

1.7 Нужны ли дополнительные меры по уведомлению участников об обсуждении удаления / объединения шаблона. Если нужны, то какие по вашему?

Возможные варианты ответов: не нужны; нужны, в варианте en:Wikipedia:Templates for discussion, шаблон по типу КУ, уведомление проектов по типу уведомления КУ и КМП от нирвана бот, по списку проектов которые записались на подстранице шаблона, свои варианты…

1.8 Нужно ли регламентировать в правилах отображения в шаблонах в спецрежимах (поддержка визред, мобильная версия, поддержка устройств чтения с экрана)

Возможные варианты ответов: жестко регламентировать, рекомендовать, не учитывать.

2 Блок частных вопросов

2.1 Шаблоны-дубликаты

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

2.1.1 Какие шаблоны считать дубликатами?
а) имеющие один функционал, но разное оформление (если функционалом не является оформление);
Возможные ответы: да/нет
б) отличающиеся малым (1-3) количеством второстепенных (ненужных для значительного массива статей) параметров;
Возможные ответы: да/нет
в) отличающиеся заметным (более 3) количеством второстепенных параметров;
Возможные ответы: да/нет
г) отличающиеся малым (1-3) количеством ключевых параметров;
Возможные ответы: да/нет
д) иное.
Возможные ответы: в свободной форме
2.1.2 Допустимо ли создание и использование шаблонов-дубликатов?
Возможные ответы: да/с ограничениями/нет/иное
2.1.2.1 Если создавать будет допустимо с ограничениями, то какие ограничения следует предъявлять к создаваемым дубликатам?
а) количественные — создание допустимо начиная с некоторого предполагаемого количества включений;
Возможные ответы: да (+граничное количество)/нет
б) функциональные — начиная с некоторого количества параметров, отличающих дубликат от исходного шаблона;
Возможные ответы: да (+граничное количество)/нет
в) хронологические — только на период времени, не превышающий T0;
Возможные ответы: да (+желательное значение T0)/нет
г) иные ограничения.
Возможные ответы: в свободной форме
2.1.3 Допустимо ли создание дубликатов, отличающихся от исходного шаблона лишь оформлением (если именно оформление не является основным функционалом шаблона)?
Возможные ответы: да/нет/иное
2.1.4 Следует ли участнику, желающему создать дубликат, сначала попробовать внести недостающий функционал в исходный шаблон, а при несогласии других участников — искать консенсуса на СО шаблона, на форумах и т. д. прежде, чем создавать дубликат?
Возможные ответы: да/нет/иное
2.1.5 Следует ли удалять дубликаты, создание которых было обусловлено не объективными причинами, а личными предпочтениями автора и автор не смог привести веских логических доводов в пользу существования шаблона?
Возможные ответы: да/нет/удалять с отсрочкой
2.1.6 Если вы считаете название шаблон-дубль неподходящим, как бы вы его назвали
а) шаблон-дубль ничем не хуже остальных, пусть будет
б) шаблон-форк
в) шаблон-копия
г) свой вариант
2.1.7 Поддерживаете ли Вы унификацию шаблонов?
Возможные ответы: да/нет, просьба указать почему
2.1.8 При каком количестве частных шаблонов стоит создавать общий?
Возможные ответы: 2-3/менее 50/ менее 100 / иное

2.3 Шаблоны-обертки

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

2.3.1 Поддерживаете ли Вы регулирование создания шаблонов-оберток?
Возможные ответы: да/нет
2.3.2 При каких из перечисленных ниже условий допустимо создание шаблонов-оберток?
а) Когда количество параметров, могущих быть предзаполненными (общих для группы статей), превышает количество параметров, нуждающихся в индивидуальном заполнении (пример — шаблоны-источники: библиографическое описание заполняется единожды и в шаблоне, а в статьях проставляются только страницы и названия разделов);
Возможные ответы: да/нет/иное
б) Когда для группы статей существует строго определённое множество параметров, являющееся подмножеством множества параметров общего шаблона (пример — различные обертки шаблона «карточка»);
Возможные ответы: да/нет/иное
в) свой вариант ответа, свои предложения
Возможные ответы: в свободной форме
г) Ясно, что подмножество параметров из п. б) должно быть заметно меньше множества параметров общего шаблона, потому как иначе проще использовать общий. Однако, стоит провести ориентировочную границу отношения их величин при которой создание шаблона-ответвления признаётся допустимым. Какой вариант поддерживаете?
Возможные варианты: 1/3, 1/2, 2/3, 3/4, иное

2.4 Отдельные группы шаблонов

Здесь рассматриваются вопросы, касающиеся отдельных групп шаблонов и не относящиеся к шаблонам в целом.

2.4.1 Тестовые шаблоны

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

2.4.1.1 Нужно ли регламентировать создание/использование тестовых шаблонов?
Возможные ответы: да/нет
2.4.1.2 Поддерживаете ли следующую схему работы с тестовыми шаблонами:
а) тестовый, экспериментальный, демонстрационный шаблон должен содержать указание на свою экспериментальность. Это может быть его создание в Песочнице или на подстранице основного шаблона, соответствующая надпись на странице шаблона или в его коде и т. д.;
б) после потери актуальности экспериментальный шаблон должен быть удалён;
в) запрещаются массовая простановка экспериментальных шаблонов в основном пространстве, а также их использование в ОП иначе, чем с демонстрационными целями либо целями тестирования (в случае невозможности тестирования в специально предназначенных для этого местах)?
Возможные ответы: да/нет/иное
2.4.2 Шаблоны-украшения

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

2.4.2.1 Нужно ли регламентировать создание/использование шаблонов-украшений?
Возможные ответы: да/нет
2.4.2.2 Что нужно для создания/применения таких шаблонов?
Возможные ответы:
а) желание автора шаблона;
б) консенсус группы участников (проекта), активно правящих статьи, относящиеся к области знаний, в которой планируется применение шаблона;
в) общевикипедийный консенсус;
г) иное.
Источник — https://ru.wikipedia.org/w/index.php?title=Арбитраж:Шаблоны-карточки_персонажей/Набор_рабочей_группы/Разбор_кейсов&oldid=130308810