Size: a a a

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

2020 February 17

VS

Vadim Smelyanskiy in DocOps-сообщество
point
> Во всех средах разработки что я знаю есть кнопка для скрытия всех комментов в файле. Как разраб, я не очень понимаю, о какой когнитивной нагрузке речь

ок, значит не ваш кейс.

> Пометки вида "к релизу 1.0" для доки делает git. Сами собой хеши коммита, и по науке git tag.

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

> Как ваш инструмент решает проблему с комментами вида "method get-user-id returns user id"?

Никак. Это не наша работа. Если инженер хочет оставить такую доку — его право. Кажется, такой код не пройдет code review

> Что вы называете "relevance factor"?
Релевантность ранее добавленной доки на сегодняшний момент. Например, выкатывали новый лендинг, в качестве доки прикрепили дизайн. Потом прошло 100 хотфиксов этой вёрстки, а дока не обновлялась. Вот мы даём понять, на сколько такой доке можно доверять по состоянию на сейчас.

> Для чего и куда вы прикрепляете исходные PDF с общей постановкой?
Простите, не понял вопроса.

> Подшивать внешние доки к версиям нужно вручную, верно? Если да, чем это отличатся от раздела на конфлюенсе с набором ссылок, куда тоже приходится вручную всё собирать?

“Подшивать” или нет — дело ваше. Вместо построения сложных иерархий, мы даём возможность тегирования. С помощью тегов удобно, например, собирать доки к очередному релизу
"> Для чего и куда вы прикрепляете исходные PDF с общей постановкой?
Простите, не понял вопроса."

Цитата из вашего питча:
"Плюс сюда добавляются проблемы, если в качестве доки у нас какая-ть pdf-ка с customer requirements, картинки с дизайном или файл на гуглодоке."

Так вот, раскройте, пожалуйста, проблему, и как ваш продукт её решает
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
Vadim Smelyanskiy
"> Для чего и куда вы прикрепляете исходные PDF с общей постановкой?
Простите, не понял вопроса."

Цитата из вашего питча:
"Плюс сюда добавляются проблемы, если в качестве доки у нас какая-ть pdf-ка с customer requirements, картинки с дизайном или файл на гуглодоке."

Так вот, раскройте, пожалуйста, проблему, и как ваш продукт её решает
"> Как ваш инструмент решает проблему с комментами вида "method get-user-id returns user id"?

Никак. Это не наша работа."

Туда же, ваша цитата: "но отлично, что java-doc есть — в 99% его или нет, или это текст типа “method get-user-id returns user id”"

Мне показалось, или это было противопоставление вашего продукта java-doc'у?

Вами затронуты проблемы, которые правда хотелось бы решить, но я пока не понял, в чём заключается предложенное решение
источник

p

point in DocOps-сообщество
Vadim Smelyanskiy
"> Для чего и куда вы прикрепляете исходные PDF с общей постановкой?
Простите, не понял вопроса."

Цитата из вашего питча:
"Плюс сюда добавляются проблемы, если в качестве доки у нас какая-ть pdf-ка с customer requirements, картинки с дизайном или файл на гуглодоке."

Так вот, раскройте, пожалуйста, проблему, и как ваш продукт её решает
на примере: сверстали лендинг согласно брендбуку. В нём цвета, элементы, вот это всё. Чтобы дать подсказку себе в будущем, или новичку, который заходит на проект, где брать те самые цвета и вообще общий стиль чтобы что-то попроавить, хорошей идеей было бы прикрепить эту PDF-ку собственно к файлу с лендингом.
В случае, если используются java-doc описания, то мы можем приложить лишь ссылку в исходник. Для этого надо эту pdf-ку куда-то залить, вставить ссылку и следить, чтоб эта ссылка была доступна и её случайно никто не удалил/перенёс.
Мы же предлагаем залить её у нас, и прикрепить её в котексте nots. Позже, на эту доку можно зайти из редактора (или сразу увидеть в системе), кликнуть и скачать себе.
источник

p

point in DocOps-сообщество
Vadim Smelyanskiy
"> Как ваш инструмент решает проблему с комментами вида "method get-user-id returns user id"?

Никак. Это не наша работа."

Туда же, ваша цитата: "но отлично, что java-doc есть — в 99% его или нет, или это текст типа “method get-user-id returns user id”"

Мне показалось, или это было противопоставление вашего продукта java-doc'у?

Вами затронуты проблемы, которые правда хотелось бы решить, но я пока не понял, в чём заключается предложенное решение
> Мне показалось, или это было противопоставление вашего продукта java-doc'у?
Мы не противопоставляем себя никому 🙂 А хотим показать, что вот есть еще один путь вести доки. Такой, немного инженерно-ориентированный.
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
point
на примере: сверстали лендинг согласно брендбуку. В нём цвета, элементы, вот это всё. Чтобы дать подсказку себе в будущем, или новичку, который заходит на проект, где брать те самые цвета и вообще общий стиль чтобы что-то попроавить, хорошей идеей было бы прикрепить эту PDF-ку собственно к файлу с лендингом.
В случае, если используются java-doc описания, то мы можем приложить лишь ссылку в исходник. Для этого надо эту pdf-ку куда-то залить, вставить ссылку и следить, чтоб эта ссылка была доступна и её случайно никто не удалил/перенёс.
Мы же предлагаем залить её у нас, и прикрепить её в котексте nots. Позже, на эту доку можно зайти из редактора (или сразу увидеть в системе), кликнуть и скачать себе.
Имхо, если команда озабочена ведением требований, дизайн у них уже лежит в Figma/Avocode/Zepplin и иже с ними;
А если она требования к дизайну не ведёт, то когда их этому научат, они скоро вырастут до Figma/Avocode/Zepplin, потому что из PDFки всё ещё менее удобно вытаскивать инфу по дизайну, чем из спец.инструментов

Можно в личке подискутировать, чтобы тут не оффтопить, но кажется, ЦА не очень проработана

P.S. мне правда интересен продукт, вопросы вида "почему тут такой странный код" – это вечная боль 🙂
источник

ЕД

Егор Доронин in DocOps-сообщество
Zepplin это только первый шаг к нормальной дизайн-системе) Недавно в ленте встретилось: команда разработчиков инструмента для распределенных команд notion.so работает из одного опенспейса, потому что попробовали remote-first и не зашло
источник

ЕД

Егор Доронин in DocOps-сообщество
Для поиска причин странных решений есть джира, где обычно это написано
источник
2020 February 18

RG

Ramil G in DocOps-сообщество
Кто-нибудь может мне объяснить, почему при всей крутизне asciidoc and rst, никто из не выбирает? каждый день появляются все новые и новые инструменты для работы с markdown.
источник

RG

Ramil G in DocOps-сообщество
Почему при аццкой крутизне org-mode он ещё не стандарт?
источник

iv

iakov v in DocOps-сообщество
Ramil G
Кто-нибудь может мне объяснить, почему при всей крутизне asciidoc and rst, никто из не выбирает? каждый день появляются все новые и новые инструменты для работы с markdown.
высокий порог входа
источник

RG

Ramil G in DocOps-сообщество
iakov v
высокий порог входа
Не думаю, что дело именно в этом. Ведь там синтаксис плюс-минус одинаковый. Видимо, я упускаю из виду какой-то критерий
источник

СФ

Семён Факторович in DocOps-сообщество
экосистема инструментария вокруг md шире, и расширяется она тоже быстрее
источник

СФ

Семён Факторович in DocOps-сообщество
раз экосистема больше, то и последователей больше, раз больше последователей, то они расширяют именно эту экосистему (а не rst/asciidoc)
источник

СФ

Семён Факторович in DocOps-сообщество
замкнутый цикл
источник

L

Lana in DocOps-сообщество
Ramil G
Кто-нибудь может мне объяснить, почему при всей крутизне asciidoc and rst, никто из не выбирает? каждый день появляются все новые и новые инструменты для работы с markdown.
Мы использовали rst, но разработчики его учить отказались пришлось добавить конвертацию из md в rst, а писатели продолжили писать rst, просто md уде все знают из-за гитхаба и подобного, реально порог вхождения, умноженный на лень 🦥
источник

iv

iakov v in DocOps-сообщество
Ramil G
Не думаю, что дело именно в этом. Ведь там синтаксис плюс-минус одинаковый. Видимо, я упускаю из виду какой-то критерий
не соглашусь. md сознательно сделан очень простым за счёт отказа от многих полезных штук, которые есть в asciidoc и rst, но делают их сложнее
источник

NV

Nick Volynkin in DocOps-сообщество
Ramil G
Не думаю, что дело именно в этом. Ведь там синтаксис плюс-минус одинаковый. Видимо, я упускаю из виду какой-то критерий
Одна и та же ссылка в Md и reST:

[Example](https://example.com)
`Example <https://example.com>`_
источник

NV

Nick Volynkin in DocOps-сообщество
Md сильно проще.
источник

NV

Nick Volynkin in DocOps-сообщество
Ещё у reST ужасная, старперская, насквозь академическая документация. Они называют ссылки hyperlink targets. Вы видели вообще живых людей, которые бы так называли ссылки?
источник

RG

Ramil G in DocOps-сообщество
Nick Volynkin
Одна и та же ссылка в Md и reST:

[Example](https://example.com)
`Example <https://example.com>`_
Дьявол в деталях
источник