Обсуждение Википедии:Статьи о программах и утилитах/Архив/1

message: Я бы предложила выстроить обсуждение следующим образом: вначале достичь какого-то согласия в части объема сведений, которые должны быть включены в статью в качестве весьма желательных  и в качестве опциональных. Минимальные требования - это грань для КУ, весьма желательные - вероятно, грань для КУЛ. Таким образом прояснится структура статьи. И лишь затем формулировать текст руководства к каждому элементу. --Томасина 23:29, 12 октября 2014 (UTC)
Модальность рекомендаций мне тоже хотелось бы видеть более мягкой: не требование, а пожелание; не запрет, а предостережение. Ведь жёсткие в Википедии только правила, да и они тоже не жёсткие. Наличие же запретов и требований в руководстве приведёт к ненужным спорам по поводу удаления статей. Руководство - это инструмент для помощи авторам в создании статьи, я так понимаю. Вот и должно оно помогать, а не ставить рамки. --Томасина 23:29, 12 октября 2014 (UTC)
* Я не возражаю против Вашего предложения выстраивания обсуждения, т.е. определиться со структурой и с тем какие из разделов весьма желательны а какие опциональные, а потом сформулировать описание. Единственное, я считаю нужным опираться на уже созданную структуру, а не создавать все с нуля. А по созданной структуре обсуждение может быть следующее: во первых отбрасываем стандартные разделы («Введение» и от «См. также» до «Категории»), чего их обсуждать? Во вторых наличие таких разделов как «История» и «Критика» в качестве весьма желательных думаю ни кем не будет ставится под сомнение, а значит и их нечего обсуждать. Раздел «Платформа», в соответствии с ВП:МТЗП также является желательным. В итоге у нас для обсуждения остается основная часть статьи с её разделами «Возможности», «Интерфейс» и «Популярность». Эти разделы были выработаны мной при анализе статей от I категории (считаю брать для анализа статьи II категории и ниже неприемлемым ввиду их сырости) до избранной из :Категория:Статьи проекта Свободное программное обеспечение по уровню и :Категория:Статьи проекта Информационные технологии по уровню, правда при анализе последней категории, нужно выискивать статьи о софте, т.к. в ней присутствуют статьи и о железе.
replies: text: На счёт модальности рекомендаций, т.е. не требование, а пожелание; не запрет, а предостережение, полностью согласен с Вами, как и с тем что нельзя ставить рамки в руководстве, просто в виду не очень большого опыта я применил неудачные фразы. Спасибо за замечание.  Volovik Vitaly 06:45, 13 октября 2014 (UTC)
replies: text: : Мне не нравится "Критика", лучше "Отзывы". Напишите здесь, пожалуйста, какая в итоге структура получается, выделив минимальные, желательные и опциональные разделы шрифтом. Преамбулу исключать не нужно, потому что в рекомендациях можно будет предложить ее состав --Томасина 09:22, 13 октября 2014 (UTC)

text: :* На счет переименования раздела «Критика» в раздел «Отзывы». Здесь все же спорный вопрос и если Вы сейчас не согласитесь с моими аргументами, придется достигать консенсуса. С одной стороны, как вариант, можно раздел «Отзывы» сделать основным, а раздел «Критика» сделать его подразделом. Но с другой стороны, считаю что слово отзывы не совсем применительно к программам. Это можно в статьях о фильмах иметь раздел «Отзывы», где действительно имеются положительные и отрицательные отзывы кинокритиков. А программы не оцениваются отзывами. Программы оцениваются обзорами и тестами, а вот им как раз место в разделе «Ссылки». А в пользу того что переименовывать раздел «Критика» в раздел «Отзывы» говорит еще вот какой пример. В хорошей статье Ubuntu, есть раздел Слежка за пользователями, который по сути является критикой, т.е. если бы критики было больше, то логично бы было создать раздел «Критика», где бы разместился подраздел «Слежка за пользователями». А теперь представьте себе этот подраздел в разделе «Отзывы»? Опять же раздел «Критика» был взят во первых из руководства ВП:ЛЯПЫ (правда там речь идет о компьютерных играх, но это не суть), где сказано: «Сведения об ошибках и неточностях желательно излагать в виде связного текста, при необходимости выделив его в отдельный раздел „Критика“», т.е. идет явная рекомендация о создании именно раздела «Критика». А во вторых, при анализе статей по указанным мною выше критериям, становится ясным, что всегда используется раздел «Критика» и не разу я не встречал раздела «Отзывы» (напр. Chromium, Opera). Решение проблемы я вижу следующее, по мимо самостоятельного раздела «Критика», должен появится раздел «Награды», т.к. многие печатные издания награждают тот или иной софт различными наградами, которые и будут указываться в разделе «Награды» в роли положительных отзывов. Такой раздел есть у хорошей статьи Mozilla Firefox, а вот у избранной статьи Opera есть как раз и разделы «Критика» и «Награды». Собственно сейчас я практически уверен, в том что раздел «Награды» необходим, но ни как самостоятельный, а входящий в раздел «Популярность».  Volovik Vitaly 11:38, 13 октября 2014 (UTC)
thread_title:  Как обсуждать 

message: предлагаемая мной структура (легенда: минимальные, желательные, опициональные): 
* Введение
* История
** История версий
* Возможности (или все же Возможности?)
* Интерфейс
* Популярность (или все же Популярность?)
** Редакции (или все же Редакции?)
** Положение на рынке (или все же Положение на рынке?)
** Награды
* Критика
* Платформа
** (Системные требования???) - прошу высказать мнение о необходимости этого подраздела.
* Интересные факты (как же я мог забыть про него )
* См. также
* Примечания
* Литература
** Рекомендуемая литература
* Ссылки
* Категории
--Volovik Vitaly 11:50, 13 октября 2014 (UTC)
Предлагаю так подправить:
replies: text: : Введение → Преамбула (потому что ВП:Преамбула)
replies: text: : История → История создания (версии — опциональный подраздел; в большинстве случаев будет достаточно упоминания версий в тексте)

text: : Возможности → Описание, в том числе интерфейс и что там еще нужно.

text: : Платформа (подняла повыше), системные требования здесь или в описании, если нужно

text: : Лицензия / условия распространения?

text: : Популярность категорически не это слово! Может быть, Распространение? Положение на рынке — хорошо.

text: : Критика — если предполагается, что здесь программу будут только ругать, то пусть будет критика. А где будут приведены хвалебные отзывы?

text: : Награды — вполне достойны отдельного раздела

text: : Интересные факты — нет, это уже давно считается дурным тоном. Энциклопедически полезная информация должна быть в основном тексте, а бесполезная — в топке.

text: : См. также — опциональный, и не слишком желательный раздел.

text: : Примечания

text: : Литература — нет, не рекомендумая литература, ВП:НЕКАТАЛОГ. Этот раздел предназначен для указания источников, использованных при написании статьи, если их нет в сносках. Это опциональный раздел

text: : Ссылки — опциональный

text: : Категории выделять в отдельный раздел не нужно, хотя в руководстве следует уделить им небольшой абзац.
--Томасина 12:43, 13 октября 2014 (UTC)
* Литература обычно содержит часто используемые источники, чтобы можно через них ссылки ставить (мне во всяком случае больше нравится, когда все источники, упомянутые более раза и важные для темы были бы в этом разделе. Кроме того, нужно описать предметную область программы, особенности программы в работе с этой предметной областью, понятия и т. п. Вот тогда статья не будет напоминать каталог. Поэтому Описание может быть весьма большим разделом. Рекомендуемая литература тоже может быть, но такое редко встречается в статьях о программах. РоманСузи 12:57, 13 октября 2014 (UTC) Кроме того, можно описать возможности по расширению (плагины), интеграцию с другими системами, Сферу применения, может быть, о Сообществе пользователей или разработчиков... РоманСузи 13:01, 13 октября 2014 (UTC)
* Введение → Преамбула - Я здесь затрудняюсь определиться, отстаивать свою позицию или согласится с Вашей. Поэтому нужно ещё чё то мнение, на сторону которого я скорей всего и встану. Хочется сделать пояснение. Название «Введение» было взято с аналогичного о компьютерных играх, это во первых. Во вторых, оно более понятно чем какая то там Преамбула, о которой я впервые услышал здесь на Википедии, т.е. думаю и других новичков это слово может сбить с толку. Ну а в третьих, я ведь как раз таки и сделал в слове «Введение» ссылку на ВП:Преамбула. Итог: для меня не принципиально, ждем еще мнений.
* История → История создания - По поводу желательно или опционально. Собственно для меня не так важно, но замечу, раздел «История» идет практически в любом документе как обязательный и при этом практически всегда первым, будь то статья в журнале или какой нибудь реферат студента. На счет того что «История версий» опционально, я согласен, но здесь есть такой забавный момент. При разработке структуры я обратил внимание на хорошую статью SuperCalc, где раздел версий занимает чуть ли не 90% статьи, т.е. вот Вам и опционально, кстати это не единственная статья где большинство информации отведено версиям. Итог: для меня абсолютно не принципиальны, пусть будет опционально.

text: На счет добавления к слову «История» слова «создания», то мне честно говоря это кажется лишним, т.к. нет особой нужды в таком уточнении. Ведь это по умолчанию подразумевается что история создания или например история разработки, кстати так вроде как правильней, ибо программы разрабатываются а не создаются. О, вот Вам пожалуйста и проблема, как все же правильней, именно поэтому мне кажется что лучше использовать более универсально и краткое «История». Кстати могу привести пример из статьи Mozilla Firefox, где есть основной раздел «История» и 4 подраздела, очень гармоничных в данном случае, один из которых как раз о создании самой программы. Итог: Не желательно.
* Возможности → Описание - Честно кажется совсем не удачная замена. Описание чего сразу хочется спросить? интерфейса? программы? Да, описание программы. И чего о ней описывать? Возможности? Правильно, под словосочетанием «описание программы», подразумеваются в первую очередь её возможности. Так почему бы сразу и не назвать «Возможности»? Я считаю этот раздел самый основной, после преамбулы, т.к. в нём будут указываться именно возможности, т.е. что конкретно умеет программа. Опять же во всех статьях из указанной мной категории, применяется слово «Возможности» (напр. SimpleBurn, Mozilla Firefox, Opera) и ни в одной из статей не применяется слово «Описание». Итог: не согласен.
* Интерфейс - трудно сказать где быть этому разделу. С учетом имеющихся статей, где то он идет как самостоятельный, а где то как подраздел «Возможности», хотя я все же считаю это не правильным, т.к. возможности это возможности, а интерфейс это интерфейс. Итог: может пока не стоит трогать этот раздел, пока с остальными не разберемся.
* Платформа → Платформа - А почему Вы перевели этот раздел в опциональный? Если его наличие требует ВП:МТЗП? На счет повыше. Опустив его практически в самый низ, я исходил из того что платформа это в какой то мере системные требования, а они в свою очередь, как правило, располагаются в самом конце какого либо руководства. Что касается примеров на статьях, то где то он ближе к верху (Opera), где то ближе к низу (Mozilla Firefox. Итог: требуется мнение других участников.
* Лицензия / условия распространения? - Посмотрите абсолютно любые статьи о программах, Вы там не увидите такого раздела! А увидите то, что во первых лицензия указывается в карточке программы, а во вторых о ней пишут в преамбуле, сразу за названием самой программы, т.е. лицензия как правило итак указывается 2 раза, зачем еще создавать целый раздел под неё? И что Вы будете писать в этом разделе? Одно слово Shareware или Freeware? Сразу могу предположить что Вы мне укажите на Mozilla Firefox, где есть здоровенный раздел Лицензии, но при этом если Вы внимательно изучите его, то поймете что эта история лицензий! Итог: категорически против.
* «Популярность», «Распространение» или «Положение на рынке» - Я взял более обобщенное для мобильности, т.е. популярность программы. Положение на рынке это что? Популярность, т.е. раздел «Положение на рынке» может быть подразделом «Популярность». Если обратиться к существующим статьям, то здесь четкого определения нет, напр. у SuperCalc их объединили: «Популярность и рыночная доля», у Mozilla Firefox, раздел «Доля рынка» является подразделом «Популярность», а у Opera как раз «Положение на рынке». Собственно я согласен с тем что «Популярность» как то несерьезно звучит для раздела. Предварительный итог: Согласен с переименованием в раздел «Положение на рынке» (хотя если честно то же звучит как то... ну да ладно).
* Награды - С одной стороны он бы неплохо смотрелся и в разделе «Положение на рынке» («Популярность»), с другой можно и отдельный раздел. Итог: согласен с отдельным разделом (если не будет претензий от других участников). 
* Критика - опустил под награды, а то как то не по людски вроде.
* Интересные факты - ну на счет раздела как такового, я не соглашусь с тем что он не нужен. Порой в какой нибудь статье ищешь только его. Другое дело что вряд ли о программах будут найдены действительно интересные факты. Можно и убрать его, чтоб он не смущал новичков и они не высасывали из пальца эти интересные факты. В любом случае, будет этот раздел в итоговом руководстве или нет, если я найду о том или ином софте действительно интересный факт, подтвержденный АИ, я непременно создам этот раздел. Итог: в целом не возражаю против удаления, но надо мнение других.
*  См. также — Итог: согласен с опциональностью 
*  Примечания - Итог: хоть по одному разделу разногласий нет 
* Литература - сразу про рекомендованную литературу. Её придумал не я, а это указание есть в руководстве, т.е. ссылка на ВП:НЕКАТАЛОГ думаю не уместна, для этого кстати написано 5-8 публикаций. С другой стороны, данный подраздел редко используется в статьях о софте и в принципе я не возражаю против того чтоб вообще не упоминать его. А вот с переводом из желаемого в опционально я бы не согласился. Сам по себе раздел «Литература» подразумевает указания на АИ из авторитетных журналов, т.е. все публикации из этого раздела не только полезны но и доказывают значимость статьи. Считаю данный раздел синонимом разделу «Примечание». Итог: подраздел «Рекомендованная литература» можно удалить, дабы не забивать участникам головы, а вот перевод раздела «Литература» в опциональные не желателен.
*  Ссылки - Итог: согласен с опциональностью
* Категории - выделил в отдельную раздел, т.к. смотрел на ВП:ОС. Я понимаю что как такового этого раздела нет, но с другой стороны и преамбулы как раздела нет, но мы же ее указали. А все потому что у нас не просто перечень разделов, а как раз таки перечень структуры. Итог: Думаю не желательно выносить категории отдельно, посмотрим что скажут другие.  Volovik Vitaly 16:41, 13 октября 2014 (UTC)
предлагаемая структура после обсуждения:
* Введение (Преамбула)
* История
** История создания
** Разработчики - внёс по предложению Романа Сузи.
** История версий
* Возможности
* Интерфейс
* Популярность или Положение на рынке (либо вместо, либо подразделом)
** Редакции
* Награды
* Критика
* Платформа
** Системные требования - проанализировал еще больше статей и ни в одной из них нет данного раздела, наверно он нарушает какое то правило, просто я не знаю какое.
* См. также
* Примечания
* Литература
** Рекомендуемая литература - убрать чтоб не забивать участником голову, не смотря на то что такой раздел подразумевается существующим руководством.
* Ссылки
* Категории
Ну вот как то так наверно. Сразу хочу обратить внимание на один момент. Это касается как раз таки предложения РоманСузи о плагинах. Я считаю что данное руководство должно быть универсальным, т.е. подходить абсолютно ко всем программам и утилитам. Это значит что из него можно было бы взять абсолютно любой раздел и этот раздел имел бы отношение к любой программе, т.е. вот те же плагины есть лишь у некоторых специфических программ и наличие такого раздела лишь забивало бы голову.  Volovik Vitaly 17:23, 15 октября 2014 (UTC)
Предлагаемая итоговая версия основных разделов (подразделы пока для примера)
* Введение (Преамбула)
* История
** Название
** Логотип
** Разработка
** История версий
* Возможности
* Интерфейс
* Положение на рынке
** Редакции
* Награды
* Критика
* Платформа
* Архитектура - РоманСузи, хочется услышать ваше мнение как программиста по этому разделу и его подразделам.
** Язык программирования
** Исходный код
** Движок
** Библиотека
* См. также
* Примечания
* Литература
* Ссылки
* Категории
Томасина Вы согласны с основными разделами?  Volovik Vitaly 00:17, 17 октября 2014 (UTC)
=== Комментарии ===
* На порядок разделов в статье должны влиять АИ. Более важные разделы передвигаются вперед. Полагаю, что об этом стоит упомянуть
* Раздел Архитектура не требует жёсткой детализации. Детали на усмотрение редактора. Иногда может объединяться с платформой.
* В любом случае, опять не вижу самого главного - описания решаемых задач
Кстати, пришла в голову мысль. Как описания делаются в т. н. фондах алгоритмов и программ. Там же можно увидеть и хороших кандидатов в названия разделов. Например,  (там есть и другие карточки)
РоманСузи 03:59, 17 октября 2014 (UTC)
* Может тогда так, будет один раздел «Архитектура» (см. ниже), без детализации подразделов, но об этом будет уточнено в самом описание к разделу, куда будет включено упоминание о решаемых задачах. Хотя смысл этого я до конца не понимаю, если это то что выполняет (решает) программа, то решаемая задача указывается в её типе, напр. Медиапроигрыватель или Графический редактор, а тип программы в свою очередь указывается в карточке и в преамбуле, т.е. дважды. Если под решаемой задачей вы понимаете назначение программы, то опять же это указывается в преамбуле, т.е. что делает программа, для чего она предназначена и т.д. В любом случае, я так понимаю что под решаемой задачей вы понимаете то, как она выполняет свои основные функции на программном уровне, а значит это из раздела «Архитектура». Если же я не правильно понимаю то что вы подразумеваете под решаемой задачей, то прошу привести примеры на 3-5 статей о той или иной программе (коих в википедии несколько сотен) со ссылкой на конкретный раздел где и описывается решаемая задача, только тогда я смогу вас понять и мы сможем определиться. По разделу «Архитектура», предлагаю такой вариант (который будет в правилах):
* Архитектура: В случае необходимости создания этого раздела, расскажите в нём об архитектуре программы, языке программирования, движке, исходном коде и т.д. Если объем информации будет большой, то рекомендуется создавать одноименные подразделы.  Volovik Vitaly 06:34, 17 октября 2014 (UTC)
** Коллега Volovik Vitaly, мне кажется, что у меня есть взаимопонимание с коллегой РоманСузи относительно того, для чего предназначена программа. Это ключевая информация, она может быть описана словом "Назначение", "Решаемые задачи". Эти понятия, в свою очередь, описываются через "функции", или, если Вам так нравится, "возможности". Мы не можем ограничиться указанием назначения программы в преамбуле, ведь преамбула - особый раздел статьи, который вкратце сообщает о содержании основной части статьи, в ней не может быть информации, которая не описана в статье. Вообще, преамбулу следует писать после того, как написана статья в целом. В описании программы её назначение - самая главная информация. Бессмысленно писать все остальное, если не сказать, зачем вообще эта штука нужна. Простыми этикетками вроде "медиапроигрыватель" или "электронная таблица" не обойдетесь. Вот, к примеру, информация об программе, достаточно объемная для создания статьи (значимость и авторитетность не оцениваю) . Какую структуру Вы предложите для ее описания? А есть её тезка. Я предлагаю Вам при осмыслении содержания руководства видеть перед собой не массовое ПО для бытового употребления, а что-то в этом роде. В структуру, которая подойдет для таких программ, "бытовуха" влезет без проблем, а вот наоборот - сомневаюсь.
replies: text: : Рассматривание статьи AutoCAD навело на мысль, что нужен еще раздел "Приложения". --Томасина 08:44, 17 октября 2014 (UTC)

text: :* Как правило, того назначения программы, которое указано в преамбуле, достаточно (речь идет именно об описании программы о не просто об указании её типа). Не буду далеко ходить, не хотел я приводить свои статьи в пример, чтоб не быть заподозренным в предвзятости к обсуждению, но видимо все же придется, т.к. так мне будет проще объяснять. Вот например 2 мои статьи о программах CrystalDiskInfo и Hard Drive Inspector. Обратите внимание на преамбулу, в ней коротко и ясно указывается не только название, тип, лицензия и разработчик, но и то главное о чем Вы с Романом говорите: во первых назначение самой программы, а во вторых то о чем говорил Роман, т.е. механизм работы программы: «Используя технологию S.M.A.R.T. Hard Drive Inspector осуществляет наблюдение за текущим состоянием различных жизненно-важных параметров...». То есть в самой преамбуле я все указал, при этом не смотря на то что описание вроде как короткое, добавить к этому в принципе нечего, а создавать целый раздел под одно-два предложение на мой взгляд абсурдно. А вот далее в статье, я более подробно раскрываю описание программы, т.е. тот же раздел «Возможности» и т.д. То есть нам теперь надо определиться, если мы правильно понимаем о чем все втроем говорим, т.е. Вы с Романом настаиваете на создании отдельного раздела описывающего назначение программы и то как она реализует свои функции, что я в принципе указал в преамбуле вышеописанных примеров, то я не возражаю на введении нового раздела «Назначение», но при этом считаю необходимым указать в описание этого раздела, что создавать его рекомендуется лишь в том случае, если преамбулы было не достаточно для полного освещения назначения программы и того как она реализует свою работу. Надеюсь так устроит всех. Если я правильно понимаю, этот раздел должен быть между преамбулой и историей. Консенсус?
replies: text: :: На счет Вашей статьи, то я как раз таки и говорю о создании универсальной структуры, подходящей для абсолютно любых программ, т.е. и для написания статьи об этой программе, я также возьму именно нашу структуру, только единственное, в ней будут специализированные подразделы, обсуждать которые не имеет смысла, т.к. для того и создается это руководство, чтоб каждый мог взять исключительно основу (основные разделы), в помощь для написания статьи, т.е. понимания о чем вообще нужно писать, а далее каждый сам руководствуется с учетом специфики софта. Давайте для примера я разберу предложенную Вами SPICE:
replies: text: :::1. Раздел «Введение» следует переименовать в раздел «Назначение», т.к. там более подробно описывается именно назначение, при этом не забываем что раздел под названием «Введение» сам по себе не правильный, ибо введение у нас это синоним преамбулы.

text: :::2. Раздел «История» точно отображает содержимое, т.е. без изменений.

text: :::3. А вот раздел «Особенности и структура программы» следует разбить. Во первых, то описание которое идет сразу под названием раздела, не что иное как популярность программы, т.е. этой информации место в разделе «Положение на рынке». А вот подраздел «Виды анализа», есть ни что иное как перечисление возможностей программы, т.е. этому подразделу место в отдельном разделе «Возможности». А раздел «Входные и выходные форматы: Netlist, schematic capture и plotting», если внимательно почитать, становится ясным что это ни что иное как содержимое подраздела «Истории версий», т.к. нам описывают что было во 2 версии программы и что добавилось в 3.

text: :::Вот так, все просто и легко можно подогнать под существующую структуру. Почему я и решил создать это руководство, т.к. если участники пишущие статьи о программах, будут его придерживаться, то и статьи о софте будут красиво и грамотно упорядочены и будет легко в них ориентироваться (а не как полный бардак в статье о SPICE), т.е. если зайдет кто либо на википедию с целью узнать чем же SPICE2 отличается от SPICE3, посмотрит, и не увидит такого раздела как «История версий» и выйдет из википедии расстроенным, ведь ему будет невдомёк искать историю версий в разделе под названием «Входные и выходные форматы: Netlist, schematic capture и plotting»!!!

text: ::: P.S. я пока здесь ответ сочинял, меня в патрулирующие перевели, умнею на глазах   Volovik Vitaly 11:05, 17 октября 2014 (UTC)
replies: text: :::: Поздравляю с флагом. С чего это "входные и выходные форматы" - история версий? Это функции/возможности. --Томасина 12:09, 17 октября 2014 (UTC)

text: :::: Посмотрела Вашу Hard Drive Inspector и ознакомилась с источниками. Боюсь, у меня имеются серьезные возражения как по структуре, так и по содержанию статьи. Я не готова принимать эту статью за рабочий пример при создании руководства и определении структуры статьи. --Томасина 13:11, 17 октября 2014 (UTC)

text: ::::* Что значит с чего это «Входные и выходные форматы» это «История версии»? С того что объясняется функционал и возможности (здесь Вы правы лишь в том, что действительно о них идет речь) 2-ой версии программы, образца 1975 (!!!) года, т.е. уже это как минимум история, история 2-ой версии программы, того как она реализовывала работу, а всему тому что относится к прошлому программы, место в разделе «История». Тут же приводится сравнение с 3-ей версии, т.е. чем 3-я отличается от 2-ой. То есть информация преподносится не так, что третья версия владеет тем то и тем функционалом и возможностью, а именно сравнивается этот функционал и возможности со 2-ой версией, т.е на лицо именно сравнение версий, место которому в подразделе «История версий». А по моей статье, вот поэтому я и не хотел их приводить в качестве примера, будем считать что и не приводил дабы не отвлекаться от обсуждения самой структуры (в любом случае уже здесь приведены около десятка статей, а есть ещё и сотни других для примера), а если у кого есть претензии к моим статьям, то на то есть и шаблоны и страница обсуждения.  Volovik Vitaly 14:16, 17 октября 2014 (UTC)
* Давайте определим, определяется ли правилом минимальная структура? В принципе, это разумно. Здесь важная граница: в правило будут тыкать, на его основании делать те или иные правки. Поэтому в правиле более всего нужен консенсус. Полагаю, что «максимальную» структуру можно описать в эссе, а еще лучше — в избранной статье по какой-нибудь программе. Поэтому в этом плане я за минимальную структуру, но с оговоркой, что статья может содержать любые другие разделы, если это необходимо и обеспечено источниками. Возможно, можно дать несколько примеров возможных разделов, но не закрытый список. Давайте вернёмся к тому, с чего началось: какие проблемы решает данное правило? После этого: решает ли данная структура эти проблемы? И конечно поздравляю коллегу Volovik Vitaly с получением флага!  РоманСузи 17:07, 17 октября 2014 (UTC)
** Спасибо за поздравление ! Роман, давайте я вас сразу немного поправлю. Мы здесь пытаемся согласовать не правило а руководство, т.е. какую бы мы структуру не разработали, ни кто и ни когда не посмеет ткнуть кого либо в неё и сказать что нужно делать вот так, потому как это будет руководство и следовать ему или нет добровольное дело каждого! Отвечая на ваш вопрос о том какие проблемы будет решать данное правило руководство. Оно лишь будет направлять по рекомендуемому пути тех, кто будет лично нуждаться в этом (как в свое время в этом нуждался я, из-за чего мне и пришла мысль создать данную структуру)! Это нужно нам всем понять в первую очередь, т.е. не правило мы согласовываем, а руководство. Кстати что касается правил, то я как раз таки категорически против того, чтоб это руководство когда нибудь стало правилом, потому как также считаю что будет не правильно если кто то будет указывать другому на эту структуру, говоря ему как нужно делать. Но в то же время, я не хочу давать этой структуре статус эссе, т.к. это... это не официальный статус, т.е. любой может написать все что ему вздумается и поставить шаблон эссе. А руководство это уже серьезный официальный документ, согласованный с другими участниками, именно поэтому мне очень хочется прийти с вами к консенсусу и я соглашаюсь со многими вашими предложениями (о введении новых разделов вроде «Архитектура», «Назначение» и «Награды», об удалении предлагаемых мной ранее разделов вроде «Интересные факты», о переименовании разделов из «Популярность» в «Положение на рынке», о изменении статуса того или иного раздела), но почему то, как мне кажется, дискуссия в каком то тупике, хотя что кого не устраивает в конкретно предлагаемой структуре, я честно не могу понять. По размеру структуры, то я тоже за её основной минимализм, но разумный, а не тот что указан в правилах ВП:МТЗП, т.к. если следовать ему, то тот минимум указывается в карточке, т.е. получается что смысла создавать структуру вообще нет. Опять же что такое минимализм? Я считаю что вот та структура которая сейчас находится в самой статье, как раз минимальна, потому как её разделы в той или иной форме (названию) есть практически в каждой статье о софте, т.к. я считаю, что ориентироваться мы должны на уже большинство существующих статей, глядя на то, какая сложилась практика. Я вот например, когда писал статьи о софте, вообще бы не подумал о разделе «Популярность/Положение на рынке», да и не нравится мне почему то этот раздел, НО... проанализировав статьи о софте, я увидел что большинство статей имеют этот раздел, т.е. мне попросту пришлось включить этот раздел в предлагаемую структуру, т.к. при чем здесь то что нравится или не нравится мне, нужно же смотреть на сложившуюся практику других участников пишущих статьи о софте. Опять же, я полностью согласен с Томасиной о трех статусах для разделов (обязательный, желательный, опционный), я честно сказать когда создал эту структуру даже не смотрел на неё с такой стороны, т.е. что у разделов должен быть статус. Поэтому я считаю что сама структура должна быть полная (но без откровенно лишних разделов), а вот в описании и будет указан её статус. Опять же я считаю что Томасина предложила правильный этап обсуждения, т.е. вначале утвердить саму структуру и лишь затем согласовать описание к каждому из разделов.  Volovik Vitaly 20:07, 17 октября 2014 (UTC)
thread_title:  Структура статьи 

message: * На порядок разделов в статье должны влиять АИ. Более важные разделы передвигаются вперед. Полагаю, что об этом стоит упомянуть
* Раздел Архитектура не требует жёсткой детализации. Детали на усмотрение редактора. Иногда может объединяться с платформой.
* В любом случае, опять не вижу самого главного - описания решаемых задач
Кстати, пришла в голову мысль. Как описания делаются в т. н. фондах алгоритмов и программ. Там же можно увидеть и хороших кандидатов в названия разделов. Например,  (там есть и другие карточки)
РоманСузи 03:59, 17 октября 2014 (UTC)
* Может тогда так, будет один раздел «Архитектура» (см. ниже), без детализации подразделов, но об этом будет уточнено в самом описание к разделу, куда будет включено упоминание о решаемых задачах. Хотя смысл этого я до конца не понимаю, если это то что выполняет (решает) программа, то решаемая задача указывается в её типе, напр. Медиапроигрыватель или Графический редактор, а тип программы в свою очередь указывается в карточке и в преамбуле, т.е. дважды. Если под решаемой задачей вы понимаете назначение программы, то опять же это указывается в преамбуле, т.е. что делает программа, для чего она предназначена и т.д. В любом случае, я так понимаю что под решаемой задачей вы понимаете то, как она выполняет свои основные функции на программном уровне, а значит это из раздела «Архитектура». Если же я не правильно понимаю то что вы подразумеваете под решаемой задачей, то прошу привести примеры на 3-5 статей о той или иной программе (коих в википедии несколько сотен) со ссылкой на конкретный раздел где и описывается решаемая задача, только тогда я смогу вас понять и мы сможем определиться. По разделу «Архитектура», предлагаю такой вариант (который будет в правилах):
* Архитектура: В случае необходимости создания этого раздела, расскажите в нём об архитектуре программы, языке программирования, движке, исходном коде и т.д. Если объем информации будет большой, то рекомендуется создавать одноименные подразделы.  Volovik Vitaly 06:34, 17 октября 2014 (UTC)
** Коллега Volovik Vitaly, мне кажется, что у меня есть взаимопонимание с коллегой РоманСузи относительно того, для чего предназначена программа. Это ключевая информация, она может быть описана словом "Назначение", "Решаемые задачи". Эти понятия, в свою очередь, описываются через "функции", или, если Вам так нравится, "возможности". Мы не можем ограничиться указанием назначения программы в преамбуле, ведь преамбула - особый раздел статьи, который вкратце сообщает о содержании основной части статьи, в ней не может быть информации, которая не описана в статье. Вообще, преамбулу следует писать после того, как написана статья в целом. В описании программы её назначение - самая главная информация. Бессмысленно писать все остальное, если не сказать, зачем вообще эта штука нужна. Простыми этикетками вроде "медиапроигрыватель" или "электронная таблица" не обойдетесь. Вот, к примеру, информация об программе, достаточно объемная для создания статьи (значимость и авторитетность не оцениваю) . Какую структуру Вы предложите для ее описания? А есть её тезка. Я предлагаю Вам при осмыслении содержания руководства видеть перед собой не массовое ПО для бытового употребления, а что-то в этом роде. В структуру, которая подойдет для таких программ, "бытовуха" влезет без проблем, а вот наоборот - сомневаюсь. 
replies: text: : Рассматривание статьи AutoCAD навело на мысль, что нужен еще раздел "Приложения". --Томасина 08:44, 17 октября 2014 (UTC)
replies: text: :* Как правило, того назначения программы, которое указано в преамбуле, достаточно (речь идет именно об описании программы о не просто об указании её типа). Не буду далеко ходить, не хотел я приводить свои статьи в пример, чтоб не быть заподозренным в предвзятости к обсуждению, но видимо все же придется, т.к. так мне будет проще объяснять. Вот например 2 мои статьи о программах CrystalDiskInfo и Hard Drive Inspector. Обратите внимание на преамбулу, в ней коротко и ясно указывается не только название, тип, лицензия и разработчик, но и то главное о чем Вы с Романом говорите: во первых назначение самой программы, а во вторых то о чем говорил Роман, т.е. механизм работы программы: «Используя технологию S.M.A.R.T. Hard Drive Inspector осуществляет наблюдение за текущим состоянием различных жизненно-важных параметров...». То есть в самой преамбуле я все указал, при этом не смотря на то что описание вроде как короткое, добавить к этому в принципе нечего, а создавать целый раздел под одно-два предложение на мой взгляд абсурдно. А вот далее в статье, я более подробно раскрываю описание программы, т.е. тот же раздел «Возможности» и т.д. То есть нам теперь надо определиться, если мы правильно понимаем о чем все втроем говорим, т.е. Вы с Романом настаиваете на создании отдельного раздела описывающего назначение программы и то как она реализует свои функции, что я в принципе указал в преамбуле вышеописанных примеров, то я не возражаю на введении нового раздела «Назначение», но при этом считаю необходимым указать в описание этого раздела, что создавать его рекомендуется лишь в том случае, если преамбулы было не достаточно для полного освещения назначения программы и того как она реализует свою работу. Надеюсь так устроит всех. Если я правильно понимаю, этот раздел должен быть между преамбулой и историей. Консенсус?
replies: text: :: На счет Вашей статьи, то я как раз таки и говорю о создании универсальной структуры, подходящей для абсолютно любых программ, т.е. и для написания статьи об этой программе, я также возьму именно нашу структуру, только единственное, в ней будут специализированные подразделы, обсуждать которые не имеет смысла, т.к. для того и создается это руководство, чтоб каждый мог взять исключительно основу (основные разделы), в помощь для написания статьи, т.е. понимания о чем вообще нужно писать, а далее каждый сам руководствуется с учетом специфики софта. Давайте для примера я разберу предложенную Вами SPICE:
replies: text: :::1. Раздел «Введение» следует переименовать в раздел «Назначение», т.к. там более подробно описывается именно назначение, при этом не забываем что раздел под названием «Введение» сам по себе не правильный, ибо введение у нас это синоним преамбулы.

text: :::2. Раздел «История» точно отображает содержимое, т.е. без изменений.

text: :::3. А вот раздел «Особенности и структура программы» следует разбить. Во первых, то описание которое идет сразу под названием раздела, не что иное как популярность программы, т.е. этой информации место в разделе «Положение на рынке». А вот подраздел «Виды анализа», есть ни что иное как перечисление возможностей программы, т.е. этому подразделу место в отдельном разделе «Возможности». А раздел «Входные и выходные форматы: Netlist, schematic capture и plotting», если внимательно почитать, становится ясным что это ни что иное как содержимое подраздела «Истории версий», т.к. нам описывают что было во 2 версии программы и что добавилось в 3.

text: :::Вот так, все просто и легко можно подогнать под существующую структуру. Почему я и решил создать это руководство, т.к. если участники пишущие статьи о программах, будут его придерживаться, то и статьи о софте будут красиво и грамотно упорядочены и будет легко в них ориентироваться (а не как полный бардак в статье о SPICE), т.е. если зайдет кто либо на википедию с целью узнать чем же SPICE2 отличается от SPICE3, посмотрит, и не увидит такого раздела как «История версий» и выйдет из википедии расстроенным, ведь ему будет невдомёк искать историю версий в разделе под названием «Входные и выходные форматы: Netlist, schematic capture и plotting»!!!

text: ::: P.S. я пока здесь ответ сочинял, меня в патрулирующие перевели, умнею на глазах   Volovik Vitaly 11:05, 17 октября 2014 (UTC)
replies: text: :::: Поздравляю с флагом. С чего это "входные и выходные форматы" - история версий? Это функции/возможности. --Томасина 12:09, 17 октября 2014 (UTC)

text: :::: Посмотрела Вашу Hard Drive Inspector и ознакомилась с источниками. Боюсь, у меня имеются серьезные возражения как по структуре, так и по содержанию статьи. Я не готова принимать эту статью за рабочий пример при создании руководства и определении структуры статьи. --Томасина 13:11, 17 октября 2014 (UTC)

text: ::::* Что значит с чего это «Входные и выходные форматы» это «История версии»? С того что объясняется функционал и возможности (здесь Вы правы лишь в том, что действительно о них идет речь) 2-ой версии программы, образца 1975 (!!!) года, т.е. уже это как минимум история, история 2-ой версии программы, того как она реализовывала работу, а всему тому что относится к прошлому программы, место в разделе «История». Тут же приводится сравнение с 3-ей версии, т.е. чем 3-я отличается от 2-ой. То есть информация преподносится не так, что третья версия владеет тем то и тем функционалом и возможностью, а именно сравнивается этот функционал и возможности со 2-ой версией, т.е на лицо именно сравнение версий, место которому в подразделе «История версий». А по моей статье, вот поэтому я и не хотел их приводить в качестве примера, будем считать что и не приводил дабы не отвлекаться от обсуждения самой структуры (в любом случае уже здесь приведены около десятка статей, а есть ещё и сотни других для примера), а если у кого есть претензии к моим статьям, то на то есть и шаблоны и страница обсуждения.  Volovik Vitaly 14:16, 17 октября 2014 (UTC)
* Давайте определим, определяется ли правилом минимальная структура? В принципе, это разумно. Здесь важная граница: в правило будут тыкать, на его основании делать те или иные правки. Поэтому в правиле более всего нужен консенсус. Полагаю, что «максимальную» структуру можно описать в эссе, а еще лучше — в избранной статье по какой-нибудь программе. Поэтому в этом плане я за минимальную структуру, но с оговоркой, что статья может содержать любые другие разделы, если это необходимо и обеспечено источниками. Возможно, можно дать несколько примеров возможных разделов, но не закрытый список. Давайте вернёмся к тому, с чего началось: какие проблемы решает данное правило? После этого: решает ли данная структура эти проблемы? И конечно поздравляю коллегу Volovik Vitaly с получением флага!  РоманСузи 17:07, 17 октября 2014 (UTC)
** Спасибо за поздравление ! Роман, давайте я вас сразу немного поправлю. Мы здесь пытаемся согласовать не правило а руководство, т.е. какую бы мы структуру не разработали, ни кто и ни когда не посмеет ткнуть кого либо в неё и сказать что нужно делать вот так, потому как это будет руководство и следовать ему или нет добровольное дело каждого! Отвечая на ваш вопрос о том какие проблемы будет решать данное правило руководство. Оно лишь будет направлять по рекомендуемому пути тех, кто будет лично нуждаться в этом (как в свое время в этом нуждался я, из-за чего мне и пришла мысль создать данную структуру)! Это нужно нам всем понять в первую очередь, т.е. не правило мы согласовываем, а руководство. Кстати что касается правил, то я как раз таки категорически против того, чтоб это руководство когда нибудь стало правилом, потому как также считаю что будет не правильно если кто то будет указывать другому на эту структуру, говоря ему как нужно делать. Но в то же время, я не хочу давать этой структуре статус эссе, т.к. это... это не официальный статус, т.е. любой может написать все что ему вздумается и поставить шаблон эссе. А руководство это уже серьезный официальный документ, согласованный с другими участниками, именно поэтому мне очень хочется прийти с вами к консенсусу и я соглашаюсь со многими вашими предложениями (о введении новых разделов вроде «Архитектура», «Назначение» и «Награды», об удалении предлагаемых мной ранее разделов вроде «Интересные факты», о переименовании разделов из «Популярность» в «Положение на рынке», о изменении статуса того или иного раздела), но почему то, как мне кажется, дискуссия в каком то тупике, хотя что кого не устраивает в конкретно предлагаемой структуре, я честно не могу понять. По размеру структуры, то я тоже за её основной минимализм, но разумный, а не тот что указан в правилах ВП:МТЗП, т.к. если следовать ему, то тот минимум указывается в карточке, т.е. получается что смысла создавать структуру вообще нет. Опять же что такое минимализм? Я считаю что вот та структура которая сейчас находится в самой статье, как раз минимальна, потому как её разделы в той или иной форме (названию) есть практически в каждой статье о софте, т.к. я считаю, что ориентироваться мы должны на уже большинство существующих статей, глядя на то, какая сложилась практика. Я вот например, когда писал статьи о софте, вообще бы не подумал о разделе «Популярность/Положение на рынке», да и не нравится мне почему то этот раздел, НО... проанализировав статьи о софте, я увидел что большинство статей имеют этот раздел, т.е. мне попросту пришлось включить этот раздел в предлагаемую структуру, т.к. при чем здесь то что нравится или не нравится мне, нужно же смотреть на сложившуюся практику других участников пишущих статьи о софте. Опять же, я полностью согласен с Томасиной о трех статусах для разделов (обязательный, желательный, опционный), я честно сказать когда создал эту структуру даже не смотрел на неё с такой стороны, т.е. что у разделов должен быть статус. Поэтому я считаю что сама структура должна быть полная (но без откровенно лишних разделов), а вот в описании и будет указан её статус. Опять же я считаю что Томасина предложила правильный этап обсуждения, т.е. вначале утвердить саму структуру и лишь затем согласовать описание к каждому из разделов.  Volovik Vitaly 20:07, 17 октября 2014 (UTC)
thread_title:  Комментарии 

message: Коллега, объясню мотивы, по которым я предлагаю перенести некоторые разделы из желательных в опциональные. Руководствоваться этими мотивами не обязательно, но тогда нужно выработать другие критерии. Когда я предлагала ввести три градации - обязательный, желательный, опциональный, - я разграничила их с точки зрения судьбы статьи: если нет обязательных разделов, статья не соответствует минимальным требованиям и подлежит удалению; если нет желательных разделов - статью нужно номинировать на КУЛ. Опциональные разделы, хотя и украсили бы статью, но и без них статья обладает достаточным энциклопедическим контентом, чтобы не предъявлять претензий к содержанию. В этом смысле раздел "История создания", как и другие - опциональный: хорошо, если он будет, но если его не будет, это не повод считать, что качество статьи ненадлежащее и она подлежит срочному улучшению. Напомню, что эта градация - лишь рабочая, на стадии обсуждения структуры. Совершенно не обязательно эти слова должны употребляться в документе, важность конкретного раздела можно будет прокомментировать в тексте руководства. --Томасина 10:46, 15 октября 2014 (UTC)
Дополню про опциональные разделы: без них статья вполне приемлема для википедии, но с ними может претендовать на статус хорошей. --Томасина 11:07, 15 октября 2014 (UTC)
* Я вполне согласен с такими определениями (желательный vs опциональный), все же у Вас опыта побольше. Спасибо что так подробно расписали, так мне действительно было лучше понять разницу. Я так понимаю, что вопрос о переносе из желательных в опциональные стоит только в двух разделах (с остальными я вроде как согласился): «История» и «Платформа», с учетом того что желающих высказаться на сей счет не появилось, соглашусь с Вашим предложением о переводе этих разделов в опциональные. Но опять же, получается что желательных разделов вообще нет?!!!  Volovik Vitaly 14:05, 15 октября 2014 (UTC)
** Да, получается, что пока нет. Но это ничего не значит. Когда сейчас будем наполнять разделы, там тоже могут внутри появиться желательные и опциональные. Пожалуйста, не сочтите за труд, напишите теперь новую версию структуры, и давайте начнём их наполнять вроде как подпунктами. Ах, да, про преамбулу: предлагаю употребить оба слова: Преамбула (введение) или наоборот :). В руководстве это допустимо, каждый поймет то, что ему удобнее. Преамбула как раздел есть, только она без заголовка. С Категориями - пожалуй, все-таки давайте пока оставим чтобы было, это мне :К:Википедия:Статьи без категорий навеяла. --Томасина 15:56, 15 октября 2014 (UTC)
*** Полагаю, что в статье о действительно значимом софте желательным разделом, как я уже писал, является описание задач, решаемым программным обеспечением, с указанием и раскрытием ключевых понятий предметной области, особенно, если в этом программа в чем-то уникальна. Этот раздел я считаю самым главным, и именно за счет его качества и статья должна расти до хорошей и избранной. Например, почитав статьи про git, mercurial и subversion, читатель должен не только узнать о «возможностях» — они примерно одни и те же. А вот модели контроля версий и архитектура различаются, и в этом — основная энциклопедическая ценность статей. РоманСузи 16:50, 15 октября 2014 (UTC)
**** Коллега, я полагаю, что именно из этих сведений и должен состоять раздел "описание" - это горзадо шире, чем "возможности". --Томасина 16:56, 15 октября 2014 (UTC)
**** Роман, вы знаете много компьютерных языков, написали книги по ним, вы мыслите как программист, именно поэтому вам и кажется что программный код (применил обобщенное слово) является основной энциклопедической составляющей в статье о программе. Но вынужден с этим не согласится, т.к. большинство людей являются не программистами а обычными пользователями той или иной программы, а если человек программист, то для него и существует как раз таки раздел «Рекомендуемая литература», где он может выбрать для себя подходящую для дальнейшего тщательного изучения. Вы вот в качестве примеров приводите 3 программы, но позвольте заметить, что все это системы управления версиями, т.е. очень специфические программы, которые и можно раскрыть в предлагаемой вами структуре, но при этом, данная структура не будет подходить для 99% статей об обычном софте. Я не хочу сказать что то о чем вы пишите не важно и не должно присутствовать в статье, напротив, я вам только благодарен что вы сделали акцент на этом, потому как я, в качестве простого пользователя ПО, ни когда бы не обратил на это внимания. В связи с этим предлагаю ввести новый раздел и назвать его... даже не знаю... «Работа» что ли, хотя в первую очередь хочется услышать от вас, как бы вы предложили назвать раздел, посвященный работе программы, исполнению ею программного кода, различных программных алгоритмов, т.е. все это одним-двумя словом? Кстати по описанию задач, выполняемых программой, все это указывается в преамбуле, в самом начале, хотя и коротко. Volovik Vitaly 17:45, 15 октября 2014 (UTC)
***** Да, пример неподходящий получился. Что такое обычный софт, если за пределами офисного пакета, веб-браузера, скайпа и т. п.? Кроме того, я говорил не о коде программы, хотя упоминал архитектуру — наиболее высокоуровневый «взгляд» на программу. Возьмём, например, Нотный редактор. Можно слукавить и описать программу поверхностно. А можно раскрыть особенности так, что станет ясно, какова специфика обработки нот? Может (утрирую), там просто сканы нот постранично, а может — весьма продвинутый цифровой формат, позволяющий делать нетривиальные преобразования, генерировать партитуру для всего оркестра с перелистыванием страниц в такт музыке. То есть, программа не может быть описана без существенных деталей на стыке с предметной областью. К сожалению, рекламные материалы грешат преувеличением «легкости использования» в ущерб более глубокому изложению существенных моментов в работе программы. Пример попроще: графический редактор. Обязательно нужно говорить о векторном и растровом представлении изображений, так как это - существенное свойство программы, без понимания которого грамотно использовать программу нельзя. Заметьте, я не предлагаю писать инструкцию по пользованию программы, а обозначить ключевые моменты, поняв которые, можно коротко и емко описать программу. РоманСузи 18:24, 15 октября 2014 (UTC) О названии раздела: основные сведения, основные концепции, возможно, архитектура, внутренняя структура и т. п. Использование программы тоже, если больше подходит. РоманСузи 18:28, 15 октября 2014 (UTC)
****** Вот давайте по графическому редактору. Вы говорите что нужно раскрывать принципы растровой и векторной графике в самой статье о программе? Но зачем? Это не только не нужно, это и в принципе никогда не делается. Что же тогда получится, что в каждой программе работающей с растровым изображением мы будем каждый раз описывать принципы растровой графики? Нет конечно! Мы создадим статью о растровой графике и в каждой программе работающей с ней, будем делать ссылку на эту статью, на то она и Викификация нужна. Далеко за примером ходить не надо, тот же Adobe Photoshop, там просто указывается что он растровый редактор и дается ссылка на то что такое растровая графика, т.е. кому надо углубиться в эти познания, пожалуйста. То же касается и векторной графики.
replies: text: ::::: На счет названия раздела, сразу отбросим «Использование программы», т.к нас обвинят в ВП:НЕИНСТРУКЦИЯ. А из остальных предложенный, мне кажется самый оптимальный это «Архитектура», т.е. коротко, ясно и по существу ваших предложений. Как раз аналога этому разделу у нас и нет. В него же и будут входит в случае необходимости такие подразделы как программный код, движки, плагины (расширения) и т.д.  Volovik Vitaly 19:00, 15 октября 2014 (UTC)
thread_title:  Желательный vs опциональный: договоримся о терминах 

message: Коллеги, у нас пропали лицензионные условия (это из списка минимальных требований и очень важно).  Нужно еще добавить где-то раздел об аналогах и конкурентах.
* С содержанием раздела История (три компонента) согласна (с оговоркой ниже).
* У нас нет консенсуса по поводу названия и содержания раздела Возможности/Описание. Предлагаю компоненты: назначение, целевой потребитель, платформа/ОС/системные требования... Редакции (?), интерфейс, совместимость... Что еще показывает анализ? --Томасина 17:48, 15 октября 2014 (UTC)
* Нет определенности с разделом Популярность/Положение на рынке. Мне пока не нравятся оба эти названия. Популярность не нравится однозначно, т.к. подразумевает только массовые продукты, это необоснованное сужение круга тем. Может быть, сделать его частью раздела "История"? Или наоборот, назвать его "Аналоги, конкуренты и положение на рынке"? --Томасина 17:48, 15 октября 2014 (UTC)
replies: text: * Лицензионные условия ни куда не пропадали, я же о них уже писал, то что они указываются в карточке и в преамбуле, т.е. нет никакой необходимости создавать целый раздел под одно-два слова. Раздел про аналоги и конкурентов - эти подразделы как раз будут в разделе «Положение на рынке» + в разделе «См.также». Раздел «Назначение» - он как раздел не нужен, т.к. назначение пишется в преамбуле. «Целевой потребитель» - не вижу смысла в создании такого раздела, эту информацию также можно указать одним-двумя словами в преамбуле. Вот Вам пример 1С:Бухгалтерия, что Вы предлагаете создать там раздел «Целевой потребитель» и написать в нем бухгалтеры?! Все? Согласитесь выглядеть такой раздел будет не к месту, т.к. как я уже говорил, это можно указать в преамбуле, т.е. программа используется бухгалтерами и т.д. разделу «Редакции» я все же считаю место в «Положение на рынке», т.к. различные редакции одной по сути программы, создаются для удовлетворения рынка, его спроса и способствуют как раз распространению и популярности. Роман правильно сказал, если переименовать «Возможности» в «Описание», то раздел будет очень большой, т.к. туда действительно придется скидывать много других разделов. Да и в технической документации к той или иной программы, употребляется слово «Возможности» где перечисляются основные возможности программы, а под Описанием подразумевается по сути вся инструкция к программе, т.е. это не взаимозаменяемые слова. По разделам Популярность/Положение на рынке/Распространение, согласен, что было бы неплохо найти одно технически грамотное слово являющееся синонимом всех трёх. Кстати зря Вы считаете что под «Популярность» подразумевается именно массовый продукт, лично у меня таких ассоциаций не возникает. Напротив, я читаю что в таком разделе, может писаться о том что продукт как раз таки малопопулярен и т.д.  А вот делать раздел «Популярность» частью раздела история это уж вообще грубая ошибка, т.к. под историей подразумевается прошлое, а под популярностью, текущее настоящее положение на рынке. Чтобы найти компромисс, давайте пока возьмем «Положение на рынке» вместо «Популярность», которое Вам категорически не приемлемо.  Volovik Vitaly 18:32, 15 октября 2014 (UTC)
replies: text: :* Коллега, а я уже не про разделы, а про наполнение пишу. Мне кажется, структуру по разделам мы уже более или менее согласовали. --Томасина 20:03, 15 октября 2014 (UTC)
replies: text: ::* Ну Вы до этого как то не высказывали однозначного мнения на счет того что мы согласовали структуру, вот я видимо и не так понял . Опять же, после обсуждения с Романом Сузи, выявилась необходимость в ещё одном разделе «Архитектура». Да к тому же по разделу «Возможности/Описание» я так и не услышал консенсуса, т.к. в отличие от раздела «Популярность/Положение на рынке/Распространение», эти два названия не совсем синонимы и от того как же все же будет называться раздел, существенно меняется его подразделы, т.е. не рановато ли обсуждать подразделы?  Volovik Vitaly 20:16, 15 октября 2014 (UTC)
replies: text: :::* Просто мне думается, что когда прояснится контент, станет ясным и название раздела. Архитектура, на мой взгляд - это часть описания. Видимо, я просто не понимаю, что Вы вкладываете в название "Возможности", уточните? --Томасина 20:37, 15 октября 2014 (UTC)
replies: text: ::::* раздел «Возможности» говорит сам за себя, т.е. то что умеет делать программа. Все программы делятся по типам, но при этом у программ одного типа, разные возможности (ведь это зависит от того как давно программа на рынке, сколько разработчиков ей занимаются, платность или бесплатность), одни могут что то больше, другие что то меньше. Раздел возможность для того и необходим, чтоб сравнивать между собой возможности программ одного типа. Практически на любом сайте той или иной программы, как раз и есть указания на возможности, где они перечислены для удобства сравнения с аналогичными программами. Вот пример возможностей для программы HD Tune, где пользователь может сразу наглядно сравнить эти возможности и решить для себя, хватит ли ему возможностей бесплатной версии или все же придется приобретать платную. А потом, перед покупкой, он может сравнить эту программу с другими аналогичными. А описание это как синоним слова «статья», т.е. сама статья о той или иной программе есть ни что иное как описание этой программы. И вы правильно считаете, что архитектура эта часть описание, т.е. часть статьи. Тем не менее, у той же архитектуры, несомненно должен быть собственный раздел, т.к. этот раздел сам по себе специфический и будет представлять интерес лишь для программистов вроде Романа, поэтому не нужно его мешать с другими разделами. Опять же в разделе «Архитектура», будет много других специфических подразделов, но об этом потом, когда точно определимся с основными разделами. На сколько я понял проблема осталось лишь в Возможности/Описание.  Volovik Vitaly 21:06, 15 октября 2014 (UTC)
replies: text: :::::* Ура, я поняла! Это функции. Да, раздел "Функции" уместен. Я не буду настаивать на этом названии, конечно. Но не стоит, на мой взгляд, возлагать на Википедию задачу предоставлять информацию для выбора. Посмотреть и выбрать, стоит ли покупать - это не для Википедии, ВП:ЧНЯВ. Да и мы же её на много-много лет пишем, а сколько лет нынче используются программы? Привести именно характеристики, функционал программы. --Томасина 22:17, 15 октября 2014 (UTC)
replies: text: ::::::* Ну про выбор это я так, грубо для примера, главное что Вы поняли . Посмотрите мою последнюю предлагаемую версию, если согласны с основными разделами, то отпишитесь под ней (подразделы пока набросаю ориентировочно для примера)  Volovik Vitaly 00:17, 17 октября 2014 (UTC)
thread_title:  К новой структуре 

message: Для истории: Википедия:Опросы/Утверждение нового руководства «Статьи о программном обеспечении» --Fastboy 08:38, 25 мая 2015 (UTC)
thread_title:  Результаты опроса