Если что, этот вопрос не про технологии, он про управление процессом разработки документации и её перевода.

Есть цель: хорошие доки на английском, проверенные на корректность и язык. Они полностью переведены на русский и перевод тоже проверен на корректность и язык.

Такая цель никогда не будет достигнута на 100%, потому что продукты постоянно развиваются и документация тоже должна идти вперёд. Поэтому цель на самом деле другая: непрерывно писать и переводить документацию по продуктам, делая самое важное с использованием ограниченных ресурсов, поддерживая установленный уровень качества и выполняя другие обязательства.

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

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

Всё это мне пока что очень непонятно, но очень интересно. Давайте соберемся и обсудим? Например, в эту пятницу, 19 марта, 16:00 Мск. Ссылку на созвон кину в чат незадолго до встречи.

Если что, этот вопрос не про технологии, он про управление процессом разработки документации и её перевода.

Есть цель: хорошие доки на английском, проверенные на корректность и язык. Они полностью переведены на русский и перевод тоже проверен на корректность и язык.

Такая цель никогда не будет достигнута на 100%, потому что продукты постоянно развиваются и документация тоже должна идти вперёд. Поэтому цель на самом деле другая: непрерывно писать и переводить документацию по продуктам, делая самое важное с использованием ограниченных ресурсов, поддерживая установленный уровень качества и выполняя другие обязательства.

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

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

Всё это мне пока что очень непонятно, но очень интересно. Давайте соберемся и обсудим? Например, в эту пятницу, 19 марта, 16:00 Мск. Ссылку на созвон кину в чат незадолго до встречи.

про STATIK можно почитать, например здесь:
https://medium.com/@britishpop/%D0%BA%D0%B0%D0%BA-%D1%8F-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D0%BB-statik-%D1%87%D0%B0%D1%81%D1%82%D1%8C-i-e0d478db3c3b

Но в сети сейчас много материалов даже на русском языке. Особое внимание рекомендую обратить на формат STATIK A3

Всем привет. Может, кто-нибудь поделится опытом, как в компании пишется документация для взаимодействия с мобильными разработчиками на вебсокеты и пуши. Для rest api кажется хватает спецификации openapi, а вот что делать с этими двумя вещами, ума не приложу. (:

Всем доброго дня!
Буду признателен, если кто-нибудь поделиться примером доки с описанием кода и его применения для разработчиков. Например, конфигурирование таблиц данных (ячейки, столбцы, поля, сортировка и пр. и пр.).
Впервые с таким столкнулся, но задача поставлена — приступить к выполнению :)

Всем доброго дня!
Буду признателен, если кто-нибудь поделиться примером доки с описанием кода и его применения для разработчиков. Например, конфигурирование таблиц данных (ячейки, столбцы, поля, сортировка и пр. и пр.).
Впервые с таким столкнулся, но задача поставлена — приступить к выполнению :)

Я ничего не понял, на самом деле, но раз никто не отвечает, то вот — пример документации кода для создания таблиц: https://reference.wolfram.com/language/ref/Grid.html 75 примеров, чотко, понятно.

мне кажется для такого применения линтеры и/или код-ревью гораздо полезнее, потому что дока
- де факто носит рекомендательный характер
- её забивают/забывают апдейтить
- не автоматизируется в CI/CD

Если не затруднит, то можно пример применения линтера в написании доки?

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

Жаль. В любом случае благодарю за отзывчивость!
Если вдруг у кого есть чем ещё  поделиться, то буду признателен.

Было у Никиты в канале тут

Жаль. В любом случае благодарю за отзывчивость!
Если вдруг у кого есть чем ещё  поделиться, то буду признателен.