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

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

Есть кейс на тему DocOps.
Смотрим на стандартные инструменты наподобие Asciidoctor, Sphinx, etc.
На поверхности все они решают задачу создания одного документа (одна книга, один файл, один сайт с набором страниц),
но вот у нас есть идея попробовать собрать в подобном формате базу знаний, то есть
коллекцию разнородных документов: от разных продуктов, разных сервисов, разных бизнес-процессов.
Собрать все это в общий репозиторий, провязать перекрестными ссылками.
Читать все это хочется как гипертекст, путем перехода по ссылками, плюс уметь выгрузить любую страницу в файл, чтобы отправить контрагенту как самостоятельный документ.

Тут мы упираемся в ограничения инструментов Asciidoctor, Sphinx: один проект = один документ. Например HTML-документация к программному коду в этом репозитории.
Пробовали вы решать подобную задачу?

очень странно. я на sphinx делал мультистраничный проект вполне себе.

полноценный сайт из репы с маркдаун доками.

наверно я не до конца объяснил суть: нет проблемы с многостраничностью. Суть в том что мы имеем коллекцию принципиально разнородных документов, которые хотим провязать ссылками и хранить в общем репозитории.  Из общего у этих документов будет только формат. Контент разный и о разном, они логически не являются страницами какого-то одного (пусть и большого) документа.

это контекст. А проблема?

зачем хранить в общем репозитории и провязывать ссылками?

Зачем ссылки?
- чтобы связать между собой схемы бизнес-процессов, ТЗ, проектные документы, технологические документы разработчиков

Зачем репозиторий?
- подготовка ТЗ включает в себя правку пакета документов, чтобы иметь атомарный коммит, видеть общую историю, вести ревью


Можно разбить на пакет репозиториев, но вижу такие проблемы:
1. создание документа = создание репозитория (документов сотни),  негибко
2. Задача трасировки истории правок и проведения ревью становится нетривиальной

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

>> мы пробовали делать генерацию чего бы то ни было в виде "сайта", не взетело, ибо нафиг не надо
Почему не взлетело? Было неудобно конечным пользователям или были иные причины?

>> Работа с репой со всей инфой по продукту в едином гите - супер-удобная штука
Расскажи пожалуйста что такое у вас “продукт” и какого рода информация находится в едином гите, по какому принципу вы создаете отдельные репозитории

не взлетело, потому что не давало никаких преимуществ

преимуществ по сравнению с чем?

gitlab

подскажи пожалуйста, в gitlab у вас документы в каком формате?

markdown

делали в них разные сложные схемы типа UML, BPMN, ArchiMate?

нет

мм, нам схемы критичны. Хотя вроде бы у Gitlab есть плагины для отрисовки PlantUML

Поделись пожалуйста опытом, какого рода документы у вас группирукются в один репозиторий,
есть ли связи между репозиториями