В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

DocOps-сообщество

787 membersпожаловаться на группу
2020 November 11

EN

Ekaterina Noskova in DocOps-сообщество
Vadim Smelyanskiy
Мы DocOps'им тех.задание, а не справку, так что может не совсем подходящий кейс, но расскажу

Собираем docx Pandoc'ом, выгружаем в Google Docs, а потом ручками комментарии сопоставляем с исходником.
Внешнее ревью, получается, самое узкое место во всей цепочке, но плюсы DocOps'а в целом сильно перевешивают и заставляют кушать этот кактус

Очень хочется придумать или реализовать что-то умнее, руки не доходят
почему не сделаете наоборот - сначала в гуглдоке согласовать текст, а потом уже докопсить?
источник
06:50пожаловаться#1

А

Александр Мокрушин... in DocOps-сообщество
Vadim Smelyanskiy
Мы DocOps'им тех.задание, а не справку, так что может не совсем подходящий кейс, но расскажу

Собираем docx Pandoc'ом, выгружаем в Google Docs, а потом ручками комментарии сопоставляем с исходником.
Внешнее ревью, получается, самое узкое место во всей цепочке, но плюсы DocOps'а в целом сильно перевешивают и заставляют кушать этот кактус

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

1. Из Help&Manual собирали DOCX с разделами, которые должны поменяться.
2. Писатель правил текст.
3. Файл добавляли в ECM-систему и отправляли по бизнес-процессу рецензентам.
4. Рецензенты ставили комменты или согласовывали.
5. Писатель переносил готовый текст в исходники.

Было бы здорово такой процесс оптимизировать
источник
06:54пожаловаться#2

ML

Maksim Lapshin in DocOps-сообщество
Ekaterina Noskova
почему не сделаете наоборот - сначала в гуглдоке согласовать текст, а потом уже докопсить?
потому что то, что вы описали очень неудобный процесс, а потом повесили на него шильдик «докопсить».

Или есть единая точка хранения документов, которая поддерживается технологически единой, или человек головой помнит, у кого какая версия хранится.
источник
07:35пожаловаться#3

L

Lana in DocOps-сообщество
Ekaterina Noskova
почему не сделаете наоборот - сначала в гуглдоке согласовать текст, а потом уже докопсить?
Так по такому принципу текст можно и в gitlab согласовывать, там уже давно wysiwyg и легко обьяснить все бизнес юзерам и привязка к версии/ветке/строке есть, а вот где и как согласовывать и комментить уже собранный статик сайт - вопрос
источник
08:07пожаловаться#4

EN

Ekaterina Noskova in DocOps-сообщество
Maksim Lapshin
потому что то, что вы описали очень неудобный процесс, а потом повесили на него шильдик «докопсить».

Или есть единая точка хранения документов, которая поддерживается технологически единой, или человек головой помнит, у кого какая версия хранится.
в чем неудобство? вы получаете уже согласованный док, который надо дальше прогнать по автоматизированному процессу и все. в гите у вас все сохраняется
источник
08:40пожаловаться#5

EN

Ekaterina Noskova in DocOps-сообщество
Lana
Так по такому принципу текст можно и в gitlab согласовывать, там уже давно wysiwyg и легко обьяснить все бизнес юзерам и привязка к версии/ветке/строке есть, а вот где и как согласовывать и комментить уже собранный статик сайт - вопрос
если научить в гитлабе бизнес-юзеров согласовывать, зачем потом статик еще показывать?
источник
08:42пожаловаться#6

L

Lana in DocOps-сообщество
Ekaterina Noskova
если научить в гитлабе бизнес-юзеров согласовывать, зачем потом статик еще показывать?
это хороший вопрос, нам в целом не надо, мы согласовываем всегда на уровне разметки или рендера в гитлабе, реже - сборка локально или на стейджинг, о выше проблема именно такая поднята же - как согласовывать уже собранный статик и с привязкой к строке исходника. вот тут старт обсуждения: https://t.me/docsascode/17001
Telegram
Bobba Fett in DocOps-сообщество
Так как в чате техписов меня благополучно проигнорировали, то вот

Поговорим про ревью при docs-as-code подходе?

Как осуществить код ревью исходников - понятно, но когда отдаёшь собранное (ведь оно нагляднее и не все смогут исходники прочитать, особенно если это не маркдаун, а разметка посерьёзнее), то фидбек приходит в не самом удобном виде (комменты в личку или на почту, тикеты в трекере), который в разы уступает тому же комментированию в гугле, например. Есть ли у современных генераторов режим сборки “на ревью”, который сохраняет ассоциации с исходниками, например, даёт возможность ревьеру оставлять комменты на блоках текста и генерит патч с комментами, которые накатываются на исходники и ты уже проходишь по ним. Неплохая фантазия? Что-то подобное есть? Может, кто-то использует какой-то иной подход? Или для подобного ревью ничего не придумано?
источник
08:43пожаловаться#7

ML

Maksim Lapshin in DocOps-сообщество
Ekaterina Noskova
в чем неудобство? вы получаете уже согласованный док, который надо дальше прогнать по автоматизированному процессу и все. в гите у вас все сохраняется
потому что никогда не бывает «согласованного документа», любой документ — это процесс. Его дорабатывают, вносят изменения, коррективы.

И жутко злятся, когда специалист пыхтит и бухтит «неужели не могли сразу всё продумать» и «почему мы это меняем, это же согласовали»
источник
08:47пожаловаться#8

FM

Fox Mulder in DocOps-сообщество
А почему не работает редирект с сайта на гит в виде *Edit this page*?
А так да, dpcx - головная боль.
источник
09:03пожаловаться#9

EN

Ekaterina Noskova in DocOps-сообщество
Maksim Lapshin
потому что никогда не бывает «согласованного документа», любой документ — это процесс. Его дорабатывают, вносят изменения, коррективы.

И жутко злятся, когда специалист пыхтит и бухтит «неужели не могли сразу всё продумать» и «почему мы это меняем, это же согласовали»
так работайте итерациями) у нас тоже доки постоянно меняются, согласование делается в рамках обновлений
источник
09:06пожаловаться#10

ML

Maksim Lapshin in DocOps-сообщество
Ekaterina Noskova
так работайте итерациями) у нас тоже доки постоянно меняются, согласование делается в рамках обновлений
Так мы работаем с единым источником и не мучаемся от бюрократии, вызванной плохими инструментами
источник
09:08пожаловаться#11

А

Александр Мокрушин... in DocOps-сообщество
Ekaterina Noskova
так работайте итерациями) у нас тоже доки постоянно меняются, согласование делается в рамках обновлений
расскажите, пожалуйста, как у вас процесс рецензирования происходит?
особенно интересна ситуация, когда описание новой фичи добавляется в существующую документацию.
источник
09:20пожаловаться#12

BF

Bobba Fett in DocOps-сообщество
Fox Mulder
А почему не работает редирект с сайта на гит в виде *Edit this page*?
А так да, dpcx - головная боль.
Он работает для тех, кто готов лезть в исходники, но не всем участникам процесса это комфортно и не всегда исходники лежат в открытом для ревьюера месте
источник
09:24пожаловаться#13

EN

Ekaterina Noskova in DocOps-сообщество
Александр Мокрушин
расскажите, пожалуйста, как у вас процесс рецензирования происходит?
особенно интересна ситуация, когда описание новой фичи добавляется в существующую документацию.
правки вносятся в гуглдок, согласуются, потом переносятся в репозиторий и публикуются
источник
09:33пожаловаться#14

FM

Fox Mulder in DocOps-сообщество
Ekaterina Noskova
правки вносятся в гуглдок, согласуются, потом переносятся в репозиторий и публикуются
Gdocs тормозит как незнамо что. Особенно если docx > 100 стран.
источник
09:34пожаловаться#15

А

Александр Мокрушин... in DocOps-сообщество
Ekaterina Noskova
правки вносятся в гуглдок, согласуются, потом переносятся в репозиторий и публикуются
а в гугл док тексты выносите вручную или автоматизировали выгрузку?
источник
09:34пожаловаться#16

А

Александр Мокрушин... in DocOps-сообщество
Fox Mulder
Gdocs тормозит как незнамо что. Особенно если docx > 100 стран.
можно разбивать тексты на несколько файлов, где это возможно.
100 страниц будет невыносимо и рецензировать, и править после
источник
09:36пожаловаться#17

FM

Fox Mulder in DocOps-сообщество
Александр Мокрушин
можно разбивать тексты на несколько файлов, где это возможно.
100 страниц будет невыносимо и рецензировать, и править после
Такая разбивка только добавляет хаоса, так как объяснять заказчикам (внешним). что вот тут у нас кусок про это, а тут про это... А если еще куски контента не дают полного представления ....
источник
09:38пожаловаться#18

FM

Fox Mulder in DocOps-сообщество
Я в прошлом году работал по схеме:
1. Загружал docx на Gdocs
2. Команда и заказчики оставляли комментарии
3. Лочил файл
4. Написал на vba макрос по вытягиванию комментариев, привязкой их к контенту и засовыванию всего этого бобра в таблицу.
5. Выгружал docx локаьно
6. Отрабатывал комментарии
7. Заливал обратно.
====
Как только файл превышал 50 страниц или одновременно с ним работали 3 и более людей - всё начинало ацки тормозить.
Docx - ущербный формат!
источник
09:41пожаловаться#19

А

Александр Мокрушин... in DocOps-сообщество
Fox Mulder
Такая разбивка только добавляет хаоса, так как объяснять заказчикам (внешним). что вот тут у нас кусок про это, а тут про это... А если еще куски контента не дают полного представления ....
Если заказная разработка разбита на несколько функциональных блоков, то можно объяснить и показать.

Новая фича повлияла не на все руководство пользователя, а только на определенные разделы. Вот смотрите их в документе.
источник
09:42пожаловаться#20