Size: a a a

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

2019 July 02

НН

Нац Нац in DocOps-сообщество
вот можно посмотреть как это сделано у Apple
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
спасибо, прямо то, что надо
источник

IA

Ivan Abashkin in DocOps-сообщество
Vanger
хорошо вам, когда есть облачные инструменты.. а когда низя)) приходится извращатся
faststonecapture
если сюда варез нельзя, могу в личку скинуть
источник

VB

Vladimir B in DocOps-сообщество
Vanger
мы пользуемя последнее время ShareX
спасибо, отличная прога. очень понравился редактор изображения)
источник
2019 July 04

VK

Vladimir Khineev in DocOps-сообщество
а возможно ли в гитхабе просмотреть изменения в одном файле, если после того как был отправлен пул реквест добавлялись еще коммиты, а не смотреть изменения по отдельным коммитам? то есть если открывать ветку, к-ая была отправлена на пул реквест, в режиме просмотра View File, то показывается состояние файла на момент отправки пул реквеста, а хочется еще увидеть внесенные изменения после отправки пул реквеста
источник

NV

Nick Volynkin in DocOps-сообщество
Vladimir Khineev
а возможно ли в гитхабе просмотреть изменения в одном файле, если после того как был отправлен пул реквест добавлялись еще коммиты, а не смотреть изменения по отдельным коммитам? то есть если открывать ветку, к-ая была отправлена на пул реквест, в режиме просмотра View File, то показывается состояние файла на момент отправки пул реквеста, а хочется еще увидеть внесенные изменения после отправки пул реквеста
А просто в пуллреквесте открыть вкладку Diff?
источник

VK

Vladimir Khineev in DocOps-сообщество
дока гитхаба пишет Once you've created a pull request, you can push commits from your topic branch to add them to your existing pull request. These commits will appear in chronological order within your pull request and the changes will be visible in the "Files changed" tab.  через Files Changed как вариант смотреть, пробуем, не очень удобно, но работает
источник

YF

Yurii Fisakov in DocOps-сообщество
Вчера обнаружил интересную особенность гитхабовских пулл реквестов. Создал pr на мерж ветки в development бренч, потом получил аппрув от мейнтейнера. А вот после аппрува я смог изменить целевой бренч и вмержиться в мастер.
источник

VK

Vladimir Khineev in DocOps-сообщество
а кто нибудь настраивал интеграцию zapier с slack? хочу чтобы было уведомление в канал после нажатия кнопки Merge Pull Request о новых утвержденных требованиях
источник

L

Lana in DocOps-сообщество
Сегодня была на синке с командой нового продукта (веб сервис), они просили экспертизы как им выстраивать документацию... предложила привычный и понятный мне стек, Sphinx+rst и хостить внутри продукта статику с елиной авторизацией, на что один из оунеров сказал а почему не купить готовый zen desk... и я чёт не накидала сходу нормальных аргументов))) кроме ну мы же инженеры ив любим все удобно и под себя сделать и сами. Есть идеи почему не готовое коробочное решение для доков?
источник

L

Lana in DocOps-сообщество
А-то я оказалось не мастер работы с возражениями против трёх американских продактов)))
источник

L

Lana in DocOps-сообщество
Им ещё надо i18n
источник

НН

Нац Нац in DocOps-сообщество
Свое кастомизированее можно делать за бесплатно, плюс с зендеском шаг влево шаг вправо и уже чего-то нильзя. Плюс воркфлоу с рст и сфинксом ближе будет и девам
источник

L

Lana in DocOps-сообщество
Нац Нац
Свое кастомизированее можно делать за бесплатно, плюс с зендеском шаг влево шаг вправо и уже чего-то нильзя. Плюс воркфлоу с рст и сфинксом ближе будет и девам
Ну своё тоже не бесплатно а за дорогое время инженеров, но стоит сравнить, их аргумент ровно наоборот, что готовое дешевле
источник

L

Lana in DocOps-сообщество
Нац Нац
Свое кастомизированее можно делать за бесплатно, плюс с зендеском шаг влево шаг вправо и уже чего-то нильзя. Плюс воркфлоу с рст и сфинксом ближе будет и девам
Вот про невозможность допилить под себя и ближе девелоперам нравится, но второе продуктовой команде (бизнес) не аргумент(
источник

НН

Нац Нац in DocOps-сообщество
У зендеска не самое наглядное версионирование всей внутренней штуки. Как вариант, можно угодить всем и настроить деплой rst в zendesk (писал о схожей штуке с маркдауном тут https://comments.bot/thread/B_jOM9DpS) ещё аргумент - ваша производительность выше со знакомым стеком тулз
источник

JM

Jaroslaw Martinow in DocOps-сообщество
Lana
Сегодня была на синке с командой нового продукта (веб сервис), они просили экспертизы как им выстраивать документацию... предложила привычный и понятный мне стек, Sphinx+rst и хостить внутри продукта статику с елиной авторизацией, на что один из оунеров сказал а почему не купить готовый zen desk... и я чёт не накидала сходу нормальных аргументов))) кроме ну мы же инженеры ив любим все удобно и под себя сделать и сами. Есть идеи почему не готовое коробочное решение для доков?
Кому с инструментом работать - тому инструмент и выбирать. На выходе всё равно доки.
источник
2019 July 05

FM

Fox Mulder in DocOps-сообщество
Мы как то внедрили ptc arbor text. Или как он там. Монструозный кровавый интерпрайз. Как же я плевался...
источник

L

Lana in DocOps-сообщество
Jaroslaw Martinow
Кому с инструментом работать - тому инструмент и выбирать. На выходе всё равно доки.
Вот, вот оно, заберу этот аргумент в копилку
источник

ИУ

Илья Улеско in DocOps-сообщество
Lana
Вот, вот оно, заберу этот аргумент в копилку
А вы аргументы собираете только потому, что хотите остаться в рамках привычного стека? Или не факт, что вы/ваша команда будете настраивать и _поддерживать_ документацию?
Думаю, что во втором случае нужна именно экспертиза и сравнение продуктов с учетом потребностей и ресурсов (люди/деньги/время) заказчика.
источник