Доработал проект конвертера их Asciidoctor в Open Document. Тесты подключил и теперь PRs are welcome. И сразу статью на эту тему https://habr.com/ru/post/556624/ , конечно с плачем Ярославны, потому как работы еще очень много

Ожидать можно что угодно) это вопрос к СБ,  у меня не стоит на компьютере телеграм и более того, даже к интернету его подключать нельзя, поэтому только так

Я тут с советом: Сделай сайтик для тестового использования. Как мне кажется, наибольший интерес возникнет к выводу по шаблону гост 34

Я уже у Михаила философтовские шаблоны взял, смотрю на них. С сайтом — интересная мысль. Какого рода содержание там могло бы быть? Я так понимаю — цель — помочь быстро втянуться тем, где готовит документацию по ГОСТ 34?

И по 19)

У Фрэнка Синатры была песенка такая Love and marriage... go together like a horse and carriage

Да да)

Там должно быть одно поле для загрузки файла, выпадающий список (с одним-двумя шаблонами) и кнопка

Каптча ещё

а... я понял, тогда, наверное, лучше zip грузить

докер это хорошо, но целевая аудитория этого конвертора - техписы.

А где противоречие?

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

@nmpotashnikoff а как тебе вариант с GH Actions, который собирает из исходников файлы и публикует их на GH Pages?

если ты посмотришь на https://github.com/CourseOrchestra/asciidoctor-open-document , он так и сделан: тестовые файлы собираются в GH Actions, и далее проверяются на соответствие схеме Open Document, если файл не создался или не соответствует схеме, PR не пройдёт.. На это было убита куча времени, особенно на поиск docker-image с LibreOffice, который нормально работает в GH Actions

а вот готовый GH Actions — это было бы здорово... Не думаю, что это сложно... интересно, а спрос есть, вообще многие собирают документацию в github?

А, я ещё не успел посмотреть )

Готовый подключаемый GH Action — это отличная штука. Мы используем такие в наших сборках, например https://github.com/tarantool/doc/blob/latest/.github/workflows/update-pot.yml

Честно говоря, не вполне понял предлагаемый подход:( Если не наем новых людей, то что?

В моей практике вопрос найма новых людей вставал ровно в одном случае: когда скорость накопления документационного долга была выше, чем скорость, с которой текущая команда его тушит. Например, когда новые фичи появляются быстрее, чем мы успеваем их документировать с должным качеством.

Если ситуация такова, то (в моей практике, опять же) никакими другими способами, кроме расширения команды, ее не решить.

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

А вот если проблема в чем-то другом, но кто-то (только вот кто?) предлагает решать ее расширением команды — тогда да, возможны варианты. Но в целом это какая-то странная ситуация: к руководителю документационной команды приходит кто-то и заставляет его против воли нанимать новых людей:)

ответил выше

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