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

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

Никак. Здесь нет необходимости и достаточности сразу.

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

Наткнулся тут...

«Чтобы научиться эффективно работать в Bitrix  Framework, нужно не сравнивать то, что вы знаете по другим системам, а стараться понять как то или иное реализуется в этой системе. В плане обучения «сравнительный» подход не работает. Просто отвлекитесь от старых знаний и изучите новую систему используя только знания PHP и сайтостроения, а не сравнивая идеологии и технологии. Легче будет освоить. А сравнивать будете потом, когда освоите Bitrix Framework.»

"Забудьте всё, чему вас учили..." (с) 😁

Видимо, это чтобы новички не спрашивали «а почему у вас тут всё сделано так криво»

Напомнило "Достаточно общую теорию управления"

Такое чтиво всегда ощущается как тёплое Клинское вперемешку со стокгольмским синдромом. А ведь люди искренне верят в свой выбор, ходят на всякие хакатоны с фуллстек 1С:Предприятием и т.д.

это "новая парадигма программирования" - вы ничего не понимаете

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

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

У кого-нибудь был опыт создания внутренней документации баз данных (описания таблиц, их столбцов)? Интересуют инструменты, практики и, желательно, способы интеграции с основной базой знаний.

Проблема звучит примерно так: есть десяток продуктов, больше двух тысяч таблиц и знание их назначения крайне полезно для dev, qa, support. Пока что решаю проблему шаблонами и формами mediawiki. Информацию оттуда удобно забирать по api, но мне не нравится, что это целиком ручной процесс. Новые столбцы/таблицы не появятся, пока кто-то их не обнаружит и не внесет вручную. Да и с версионированием беда.

@NortaBirdo умеет в автодокументирование БД

Николай, из тарантула вытягиваете ?

Нет, у нас MS SQL. Расширили метаданные и тянем это все питоном, генеря в rst. rst объединяются с другими rst и обрабатываются сфинкосм для генерации статитки

Запуталась в Николаях. А кому вопрос задавали про тарантула? :D

не мне

Будет о чем подумать, спасибо. Выглядит так, что проще дополнить код метаданными и расширить мое текущее решение.

Интереснейшая дискуссия о проблемах ведения доки к проектам
https://twitter.com/rothgar/status/1151730253082980353?s=19

Игорь @iafan — один из разработчиков инструментов Serge (https://github.com/evernote/serge) и Zing (https://github.com/evernote/zing). Добро пожаловать!