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

Конкретных инструментов не знаю, лучше подождать более опытных коллег, тоже послушаю. Как вариант, вводить некий класс (стиль) и выделять им термины, потом уже можно как угодно анализировать. У нас что-то подобное для элементов интерфейса.

Точно. Для тех, кто из мира js (react,angular), java (jsp,jwt) или даже php, это весьма очевидный подход.

Но я с удивлением обнаружил, что многие даже технически ориентированные специалисты продолжают набивать вордовые простыни без толики систематизации и моделирования. Жаль, что индустрия заставляет часто делать выбор в сторону "быстро и негибко".

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

Да, копипастят, увы. Копипаст зло, что в коде, что в документации. При нем умножаются затраты на рефакторинг изначального куска. А вот если передавать ссылку на изначальный фрагмент, то можно хранить и подсвечивать только дельты, например.

Вопросы копипаста в коде очень сложны, не стоит так безапелляционно заявлять

Назвать разные фрагменты кода одной функцией стоит намного дороже, чем скопировать один фрагмент один раз

если умеюче копипастить, понимать связи кусков текста в документах, то риски низкие, сроки быстрые... одно дело, если в проекте 10 документов, другое - 200 (встречалась с такими вариантами)

#wanted_tw

Вакансия: технический писатель
(https://nn.hh.ru/vacancy/42260031)

Компания: Lad (https://lad24.ru/)
Город: Нижний Новгород
Формат: удаленная работа
График: 5/2, полная или частичная занятость.

Обязанности:

- Писать новые статьи и поддерживать существующие в проектной базе знаний: онбординги; описания архитектуры; верхнеуровневые описания логики; руководства по развёртыванию и настройке среды.
- Тестировать собственные тексты: всем ли удобно и понятно пользоваться.
- Корректировать статьи, написанные разработчиками/менеджерами, если они попросят (или настаивать на корректуре).

Требования:

- готов(а) общаться с разными людьми, интервьюировать их и узнавать недостающую информацию по проекту;
- имеешь опыт работы с текстом: структура, орфография / пунктуация / стилистика, твердое "нет" канцеляризмам. Знаешь, что пишешь для людей, поэтому делаешь текст умеренно простым.
- Знаком(а) с IT технологиями: понимаешь цикл разработки приложения, основную терминологию веб-разработки, возможно умеешь читать код. Выражения "выкатить в релиз", "микросервисная архитектура" и "диспатчить экшны на стороне сервера" не должны пугать.

Мой контакт: @belyakovass.
Буду рада познакомиться :)

Проблема копипастов в документации решается инклудами, переиспользованием фрагментов или делением на топики, а вот их уже многие языки разметки и hat поддерживают

Насколько я могу судить, на DITA и DocBook такое точно можно реализовать

DocBook + Schematron внутри редактора (например, XMLMind). Это как один из примеров. Но надо предварительно заморочиться, все сделать и отладить.

Эта тема муссируется сотню лет. Нет, IDE для текста нет. И не планируется. Никто не видит рынок или стандарты, а значит не выгодно.

Так что максимум ide для кода с тонной плагинов и мелких сервисов/тулов уже на сервере, которые настроите сами. Да еще и язык разметки выбрать тип асидок, ямл, мд.

Ну, IDE понятие растяжимое.

Большинство HAT (MadCap, Help&Manual...) вполне себе можно воспринимать как IDE.

Подскажите пожалуйста, если в нормативно-правовом акте введены сокращения, нужно ли их повторно вводить в приложении к нему?
На тему оформления НПА нашел только ГОСТ Р 6.30-2003 Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов
В этом ГОСТ (как и в других ГОСТ оформления документов, которые я смотрел) данный вопрос не затрагивается.

На мой взгляд сокращения, введенные в основном тексте, повторно раскрывать в приложении не требуется, но получил замечание повторно раскрыть

если это приложение отдельным файлом, то я бы раскрыла их во втором файле тоже - иначе не стала бы

Не нужно

А есть на что сослаться в качестве обоснования?

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