Size: a a a

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

2020 September 02

NV

Nick Volynkin in DocOps-сообщество
У меня есть список именно каналов, если что: https://t.me/docops/418
Telegram
DocOps
Каналы про документацию и управление знаниями.

Давно хотел написать этот пост. Кажется, новогодняя ночь неплохо для него подходит. Я уже делал подборку чатов, а теперь напишу про каналы. Это не взаимный постинг — я им принципиально не занимаюсь. Просто перечислю всё, что сам читаю. В порядке возрастания подписчиков, чтобы эффект был равномернее. Если кого-то забыл, завтра проснусь и на свежую голову допишу.

Неожиданно, первым будет не канал, а блог на Дзене.

IT-всячина глазами технического писателя (9 читателей).
Станислав пишет нечасто, но зато там целые истории про работу техписателя.

@getdocument (25).
Автор периодически постит ссылки на хорошие статьи и видео, иногда пишет о собственном опыте обучения, например про документирование API и книгу Docs like Code. (Имя автора знаю, но в канале оно не указано, так что не пишу).

@KnowledgeConfChannel (269). Канал KnowledgeConf — конференции про управление знаниями в IT.

@shut_up_and_write Shut up and write (370).
Мария хорошо пишет про документацию со стороны…
источник

EP

Elena Parameshwari in DocOps-сообщество
Anna Ryutina
а мне все интересно, но меня раздражает обилие каналов, что делать?)
Мутить (mute) каналы и читать то, что считаете актуальным
источник

AR

Anna Ryutina in DocOps-сообщество
и так все каналы\чаты в mute, но каждый раз когда вы постите новый чат, канал, прям начинает напрягать, что я опять не в теме))
источник

FM

Fox Mulder in DocOps-сообщество
А я сегодня вступил в канал любителей аскидока)
источник

AR

Anna Ryutina in DocOps-сообщество
о -))
источник

MD

Mazin Den in DocOps-сообщество
ID:0
Пишет Игорь Цупко, мой единомышленник и соратник по KnowledgeConf:

Привет, коллеги!

Последний год мы с коллегами из KnowledgeConf занимаемся систематизацией и исследованиями подходов к менеджменту знаний и оформляем это всё в виде Прагматичного Гайда.

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

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

Чтобы принять участие — забейте временной слот (30-40 минут) через Calendly. По возможности укажите при забивании слота — какие проблемы менеджмента знаний для вас актуальны, чтобы нам не терять времени.
Пообщались сегодня с Игорем. На мой взгляд, очень продуктивно) Спасибо ему!
источник

NV

Nick Volynkin in DocOps-сообщество
Fox Mulder
А я сегодня вступил в канал любителей аскидока)
Покажи )
источник

IC

Ivan Cheban in DocOps-сообщество
Fox Mulder
А я сегодня вступил в канал любителей аскидока)
Это в телеграмме?
источник

NK

ID:0 in DocOps-сообщество
Добавил чат любителей AsciiDoctor — @asciidoctor.

AsciiDoctor — это ещё один легковесный язык разметки и генератор документации для него. Язык разметки похож на reStructuredText: выразительный, семантический но сложнее и менее популярный, чем Markdown.
https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/
источник
2020 September 05

RG

Ramil G in DocOps-сообщество
Переслано от Ramil G
Коллеги, а кто и как поддерживает актуальность пользовательской документации (help) на сайте? У нас в настоящий момент это делает один выделенный аналитик. Ему очень трудно уследить за всеми изменениями, поэтому бывает, что описание фич не попадает в доку, а бывает, что фич слишком много и аналитик просто не успевает. Думаю возложить обязанность писать доки по каждой фиче аналитиков, непосредственно ставящих задачи по этим фичам.
источник

RG

Ramil G in DocOps-сообщество
Переслано от Ramil G
Также интересно вообще мнение и опыт относительно сборки пользовательской документации из doxygen и скриншотов при помощи selenium или pappeteer
источник

NV

Nick Volynkin in DocOps-сообщество
Ramil G
Переслано от Ramil G
Также интересно вообще мнение и опыт относительно сборки пользовательской документации из doxygen и скриншотов при помощи selenium или pappeteer
Почему именно doxygen, надо код документировать?
источник

RG

Ramil G in DocOps-сообщество
Nick Volynkin
Почему именно doxygen, надо код документировать?
Мы с разработчиками поговорили, решили, что надо делать самодокументируемый сайт. Чтобы у всех элементов на сайте был небольшой кусочек текста-пояснения. Эти пояснения будут делать разработчики фронта. Надо чтобы эти куски собирались автоматически в большую отдельную доку.  Вместе со скриншотом элемента к которому они привязаны
источник

RG

Ramil G in DocOps-сообщество
Пожалуй, это как сваггер :)
источник

ML

Maksim Lapshin in DocOps-сообщество
Ramil G
Переслано от Ramil G
Коллеги, а кто и как поддерживает актуальность пользовательской документации (help) на сайте? У нас в настоящий момент это делает один выделенный аналитик. Ему очень трудно уследить за всеми изменениями, поэтому бывает, что описание фич не попадает в доку, а бывает, что фич слишком много и аналитик просто не успевает. Думаю возложить обязанность писать доки по каждой фиче аналитиков, непосредственно ставящих задачи по этим фичам.
мы сейчас сделали так: все сниппеты кода на сайте мы делаем куском теста. Т.е. если есть кусочек кода, настройки, чего-то ещё, то он должен быть прям с сайта засунут в автоматический тест (тест пишется руками под каждый сниппет) и проверен на работоспособность.


Если что-то хрустнет, значит что поведение поменялось
источник

RG

Ramil G in DocOps-сообщество
Maksim Lapshin
мы сейчас сделали так: все сниппеты кода на сайте мы делаем куском теста. Т.е. если есть кусочек кода, настройки, чего-то ещё, то он должен быть прям с сайта засунут в автоматический тест (тест пишется руками под каждый сниппет) и проверен на работоспособность.


Если что-то хрустнет, значит что поведение поменялось
Ага, автотест является индикатором, что надо переписать доку... тоже неплохо
источник

RG

Ramil G in DocOps-сообщество
А доку сама по себе живет? Доки никто не читает же
источник

RG

Ramil G in DocOps-сообщество
Хотим, чтобы пояснения были на самом сайте, при этом, чтобы большую доку не приходилось поддерживать отдельно.
источник

ML

Maksim Lapshin in DocOps-сообщество
это документация как раз на сайте
источник

NV

Nick Volynkin in DocOps-сообщество
Maksim Lapshin
мы сейчас сделали так: все сниппеты кода на сайте мы делаем куском теста. Т.е. если есть кусочек кода, настройки, чего-то ещё, то он должен быть прям с сайта засунут в автоматический тест (тест пишется руками под каждый сниппет) и проверен на работоспособность.


Если что-то хрустнет, значит что поведение поменялось
Это код для SDK, да? У нас много bash и cmd.exe, и я пока с трудом представляю, как на них написать тесты.
источник