VS
ок, значит не ваш кейс.
> Пометки вида "к релизу 1.0" для доки делает git. Сами собой хеши коммита, и по науке git tag.
Можно и так. Мы даём независимый от непосредственно репы возможность тегировать документацию. Чтоб потом безполезненно уточнять или удалять теги, относящиеся именно к документации.
> Как ваш инструмент решает проблему с комментами вида "method get-user-id returns user id"?
Никак. Это не наша работа. Если инженер хочет оставить такую доку — его право. Кажется, такой код не пройдет code review
> Что вы называете "relevance factor"?
Релевантность ранее добавленной доки на сегодняшний момент. Например, выкатывали новый лендинг, в качестве доки прикрепили дизайн. Потом прошло 100 хотфиксов этой вёрстки, а дока не обновлялась. Вот мы даём понять, на сколько такой доке можно доверять по состоянию на сейчас.
> Для чего и куда вы прикрепляете исходные PDF с общей постановкой?
Простите, не понял вопроса.
> Подшивать внешние доки к версиям нужно вручную, верно? Если да, чем это отличатся от раздела на конфлюенсе с набором ссылок, куда тоже приходится вручную всё собирать?
“Подшивать” или нет — дело ваше. Вместо построения сложных иерархий, мы даём возможность тегирования. С помощью тегов удобно, например, собирать доки к очередному релизу
Простите, не понял вопроса."
Цитата из вашего питча:
"Плюс сюда добавляются проблемы, если в качестве доки у нас какая-ть pdf-ка с customer requirements, картинки с дизайном или файл на гуглодоке."
Так вот, раскройте, пожалуйста, проблему, и как ваш продукт её решает