#wanted_tw

Всем, добрый день!

Ищу Технического писателя на проект. Мы небольшая команда, которая разрабатывает программное обеспечения для управления отоплениям при помощи IoT. У нас есть рабочая версия ПО. ТЗ для дизайнера, сам дизайн(figma) и зачаточная версия ТЗ написанная мной(то есть плохо).

Нам нужен комплект документов:
1) описание функциональности и технические характеристики ПО. (Звучит как тз)
2) инструкция по установке
3) инструкция по эксплуатации

Документы 1,2 нужны для включения в реестр отечественного по
Документ 3 нужен для удобства заказчиков, так что хотелось бы правда удобный документ.

Планов по развитию много, так что в перспективе возможно долгосрочное сотрудничество
Пишите в ЛС, спасибо

Тоже так

Думаю, вам может быть интересно сообщество https://t.me/konveerum_chat. Не по вакансии, а так, вообще.

С официальным письмом о намерениях принять на работу просите проекты документов на устройство

Всем привет! Ребята, скажите, пожалуйста, какими системами контроля версий документов вы используете/использовали в работе? Какие лучше/хуже и почему?

Расскажите, пожалуйста, какие инструменты разработки документации вы используете?

Например, у меня были проекты, где писали в Help&Manual. В инструменте была интеграция с SVN. Эту систему и стали использовать.

Сейчас использую Git

Git и только git, потому что он везде.

Mercurial хорош, но очень нишевый, его почти нигде не используют.
SVN стар и ужасен и поэтому его почти нигде не используют уже лет 10.
Ещё более ранние инструменты представляют интерес только для историков.
Специальные инструменты для (огромных) монорепозиториев есть в компаниях вроде Яндекса и Гугла. Придете к ним работать — вас научат.

> поэтому его почти нигде не используют уже лет 10

у нас пока используют 😭
но скоро переезжают на гит

На старой работе использовали Perforce. Старьё, но удобнее Гита.

Ребят, а есть стайл гайды для технических писателей? (гост не учитываем)

мне кажется в каждой компании свой (ну не в каждой конечно, но в общем кому надо, сами пишут)

часто за основу берут руководство стиля Microsoft. @matarasenko можете тоже его использовать

https://www.writethedocs.org/guide/writing/style-guides/ - тут большинство популярных перечислено

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

Привет. Работал с Perforce, TFS, Git. Perforce наверное самый удобный, потому что самый гибкий -- можно хранить двоичные данные и не бояться, что их получение из репозитория в будущем займёт миллион лет.

TFS'ом пользовался давно, наверное опыт с 2017-й версией не очень интересен сейчас, потому что Микрософт любит всё переделывать и переставлять с ног на голову с каждой новой версией чего-либо. Из удобства, так же как и в Perforce, можно хранить не только текстовые данные, например DOCX, для получение тысячной версии не надо будет скачивать 999 предыдущих версий файла. Помимо этого, в TFS было достаточно удобно связывать хранение с задачами. То есть в одном интерфейсе можно управлять как файлами, так и задачами и сборками, в которых эти хранимые файлы используются.

Но все эти системы дороги, даже очень большие конторы из сейчас не жалуют. Можно сказать, что в индустрии закрепился Git. Он вроде бы значительно быстрее работает с небольшими текстовыми данными, то есть очень хорош для разработки. А вот для технического писательства с Git'ом придётся уйти от хранения двоичных данных, Git выделяет разницу между данными в репозитории и данными на локальном компьютере по цепочке, и для получения копии 3 текстового файла нужно будет загрузить лишь дельту. С двоичными же данными придётся скачать все предыдущие копии целиком. Поправьте меня, знатоки, если я тут набрехал.

Поэтому все схемы управления технической документацией с хранением и управлением версиями в Git используют подход DocOps.

Но вот с удобством тут вопрос. Сравнение изменений, если это текст описания, а не код, не всегда удобно и просто. Как, например, просто переименовать описание в старом комите без перебазирования?

<s>Я тут книгу издал, тиражом пять тысяч экземпляров, и вдруг обнаружил ошибку — как бы мне просто исправить все ошибки во всех книгах?</s>

Ну это как раз просто. Второе издание. Исправленное и дополненное.

Аналогия: в новом push'е.

Коллеги, добрый день!
Подскажите, пожалуйста, имел ли кто дело с компанией Unlimint (они же Cardpay)? На словах просто райский оффер, на деле  очень мутный договор самозанятого, но согласны чуть подправить (не всё).

Можно в личку. Спасибо!

Мне кажется подход должен быть простой. Любые сомнения трактуются не в пользу оффера.