Сам спрошу. :) Встречал ли кто-нибудь инструмент для описания мыслекарт (mindmap) текстом? Как PlantUML для диаграмм.

Очень хочу мыслекарты на свой сайт и блог.

Текстом это как?

почему не нарисовать.? а вообще есть вроде да

я когда искала как делать текстом sequence diagrams видела

XMind умеет импортировать иерархические списки

И умеет экспорт в png, svg  и т.п.

Coggle.it подойдет?

И при запуске из консоли пишет кучу всего в нее. Возможно, можно заставить его в консольном режиме делать из CSV картинку

У Coggle унутре неонка... то есть простой джаваскриптовый D3 (перепиленный Evernote), который можно элементарно прикрутить к любой веб-странице и настроить стилями

Спасибо, завтра гляну.

Например JSON, из которого клиентский JavaScript рисует интерактивную мыслекарту. Чтобы можно было сворачивать узлы, чтобы подстраивалась под размер экрана.

Я что-то такое видел два года назад, но потерял и не могу найти.

Коллеги, добрый день

Приветствую )

Есть вопрос.

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

Есть выбор между двумя подходами:
1. Вести всю документацию в соответствии с Docs as Code.
2. Вести в соответствии с Docs as Code только сопроводительную документацию (тесты и документация разработчиков), а требования и общую документацию по системе вести в Confluence.

Дискуссионные пункты:
1. Предполагается, что система конфликтов в Git поможет находить конфликтные места документации. Однако если мы будем на неё полагаться, то будем пропускать такие вещи, как разные названия для файлов, описывающих один документ.
2. Исходный формат Docs As Code нечитаем для бизнеса. Бизнес может работать с экспортированными форматами, но это ломает процесс согласования. Например представитель бизнеса вносит комментарии в PDF, аналитик меняет исходный файл, делает новый экспорт и комментариев в нём уже нет. Вероятно проблема решается реализацией отдельной системы согласования, где комментарии будут храниться отдельно от HTML и подтягиваться к новым версиям документа.
3. Документация на систему в целом и на требования включает в себя большое количество нетекстовых артефактов (диаграммы, сторонние документы и т.д.), при использовании которых ценность подхода Docs as Code теряется. Рассматривался вариант с максимальным переходом на текстовые, но PlantUML не особо вытягивает, а сравнимых с ним средств особо нет.

Хотелось бы услышать, у кого какое мнение по этому выбору?

@PAK3APYKY Отличные вопросы!

1. Конфликтные места лучше находить специально написанными тестами. Например, тест собирает имена файлов и названия документов и проверяет, что в двух разных файлах не описаны документы с одинаковыми или почти одинаковыми названиями.

2. Не так уж и нечитаем. Например, в GitHub вся внутренняя документация компании ведётся в Markdown и хранится на самом GitHub. Для обсуждения изменений они используют мерж-реквесты. Представитель бизнеса может прийти и покомментировать, так же как он бы комментировал задачу в трекере (JIRA или тот же GitHub). Об этом рассказывал Марко Беркович: https://2017.codefest.ru/lecture/1185/