да, наверняка

Вот и настал мой черёд ))  #wanted_tw

💼 Вакансия: Стажер отдела технических коммуникаций

Компания: Group-IB (https://www.group-ib.com/)
Формат работы: офис (Москва, м. Дубровка/м. Пролетарская), по согласованию иногда можно удаленно
Занятость: от 20 часов в неделю
Писать @NatalyJones

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

Стажер будет помогать:
- описывать архитектуру, API и ключевые технологии продукта
- писать и обновлять документацию для пользователей
- формировать и публиковать release notes & system updates
- проводить интервью и вычитывать тексты перед публикацией
Если интересно, поможем в UX и научим писать UX-тексты, или в разработку и научим писать код.

В рамках документирования работаем с:
- wiki-системой для внешней документации
- документацией внутри продуктов (Git + markdown)
- внутренней базой знаний в Confluence и задачами в Jira
- интерфейсами продукта на русском и английском (JSON)

Что нужно, чтобы присоединиться к нам:
- грамотный русский и умение писать понятно и для пользователей, и для разработчиков или желание этому научиться
- уметь анализировать и структурировать большие объемы информации, работать самостоятельно и проявлять инициативу
- понимать, зачем нужна техническая документация, кто ей будет пользоваться и как её писать
- быть студентом технической специальности (в идеале - направление IT).

Будет плюсом, если вы:
- знаете английский на уровне Upper Intermediate, а еще лучше Advanced
- умеете в git и markdown
- имеете опыт документирования и/или тестирования программных продуктов
- знаете, что такое кибербезопасность, основных игроков рынка и их продукты.

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

скорее всего, просто поленились
как-то же переводится и ЩАП (щиток автоматического переключения), и ГРЩ (главный распределительный щит)
другое дело, как с такими косяками в локализации приняли)

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

и потом, маркировка на железках все равно на русском будет

ну если считать все это в комплексе (маркировки на вот таких вот табличках (древний советский UI/UX), обозначения в документации, и прочее), то да, дешевле, чем переделывать, оставить как есть
разберутся на месте

Вчера решила поискать литературу для техписов, наткнулась на утверждение, что статьи Яндекса из раздела поддержки можно считать достойно написанными.
Любопытство завело на статьи по функции поиска в Яндексе.
- Сразу отлегло...и в Яндексе разномастно пишут эти статьи... где-то  названия статей "Искать ...", где-то "Поиск...", где-то иначе - короче не однообразно, как ожидалось

@revolg, Alec, @roht0 благодарю, что поделились. Ведь действительно хотела пойти по простому пути и прикрутить голосовалку. Идея с формой обратной связи понравилась всем 👍

У нас вся документация к сожалению такая. Как с этим бороться? заводить список допустимых терминов или потом один человек должен вычитывать все документы и вносить правки?

Добрый день! Кто-нибудь может подсказать, что означает параметр "Вхождение" в документации API?

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

На одного человека всю вычитку не надо оставлять.

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

В нашей команде открыта вакансия (старшего) технического писателя. #wanted_tw

Ищем техписателя / старшего техписателя в команду разработки документации ИТ-департамента Лаборатории Касперского (https://www.kaspersky.ru/).
Полная занятость, возможен смешанный формат работы (офис + удаленка)
Офис г. Москва, м. Водный Стадион

Что предстоит делать в нашей команде:
- Разработка/обновление пакета документации (установка/конфигурация, мониторинг, API/интеграция, руководство пользователя, видео-справка, статьи для базы знаний внутреннего Service Desk);
- Согласование пакета документации с командой разработки и эксплуатационными подразделениями;
- Поддержка процесса передачи ИТ-сервисов на поддержку в части, связанной с согласованием сервисной документации, в том числе планирование привлечения технических специалистов для вычитки, координация вычитки и др;
- Вычитка документов, подготовленных вашими коллегами.

Подробное описание вакансии: https://hh.ru/vacancy/45319550

Контакт для связи в Telegram: @Anna_Sn

+1
или вовсе распараллелить процессы написания и проверки/унификации, выделив структурное подразделение по контролю качества

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

Я как то для себя определился что как бы ни перечислялось, ставлю в конце точку с запятой за каждым пунктом, кроме последнего. За последним - точка. Перечисление это особая форма предложения, в котором пункты списка подчинены вводному высказыванию. А значит, если предложение не закончено, то и точка преждевременна, а запятая тоже не очень годится :)

А вот когда я перечисляю действия нумерованно, там точки ставлю в конце каждого. Потому как одно действие с чего то начинается и к чему-то приводит.

Нумерованный список говорит о том, что у вас последовательность шагов. Каждый шаг в процедуре - это, как правило, какая-то завершенная мысль. Точка нужна в конце каждого list item, особенно если вы пишете на английском.

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

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

на англ в любом списке в конце каждого пункта точка. Майки так советуют
https://docs.microsoft.com/en-us/style-guide/scannable-content/lists

привет, а где можно посмотреть примеры ошибок в хедере запросов?

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

и вот по сути, как ошибки апи (которые видны через девтулз создателю если захочет протестировать или ему может пользователь скрин сделать)
в какой форме тут писать
(помимо того, что там где форма подписчик увидит фразу, что форма не работает, нужно обратится к владельцу сайта)
You cannot add the multiple attribute to the select tag (дак вроде и запоздало если говорить пользователю, а подписчику дак и бесполезно там обращаться)
или
Select tag with Multiple attribute is unacceptable (типа факт)
или еще какие-то варианты

будет в том месте, где красным выведено form-warning