Внутренние доки мы просто пишем в Confluence и там же оставляем.

@Nick_Volynkin , @filhodejaneiro  а как собираете одобрение коллег? там же в документе ✅ чекбарами с @ меншенами? и привязываете к задачам в джире?

да, именно checkboxes и mentions. у нас не очень много коллег, от которых требуется одобрение, и процесс одобрения не формализован

я сейчас оцениваю технику, по которой статью для подготовки документа хочу закрепить за джировской задачей и все необходимые консультации регистрировать как подзадачи. С одной стороны это может дать предмет мониторинга для МПроектом ,с другой стороны, если мудрить вируальную канбан доску, то хочу все подзадачи на каждом этапе подготовки документа отображать в "подвале" колонки по каждому из этапов. Но это сложно, гораздо сложнее, чем регистрировать внесение галочки в чекбар. Блин, если есть, кто через это проходил, поделитесь опытом.

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

Впрочем, бывает что после встречи пишем итоговый документ, там делаем чекбоксы с @user, чтобы все прочитали и дополнили.

Если вам нужен строгий процесс, посмотрите на Comala Workflows, это плагин для конфлюенса.

Мы в команде использовали Comala Workflows.
Отчеты этого плагина помогали мониторить статус каждой странице: что надо исправить, что согласовали и тд

Спасибо. Посмотрел сейчас. Интересно. Останавливает только необходимость платить. Кругом же транформации и оптимизации... поищу сейчас способ ввести стандартным макросом (фильтр задач джира) в конфлюнс с контекстым параметром в фильтре по пользователю. Чтобы вывести из фильтра только ту задачу, которая назначена на подписанта... может кто делал?

А тут спрашивали?

https://t.me/augmoscow

О! спасибо, за наводочку. Кстати, да, нашел, в фильтре можно поставить ключ с контекстом пользователя обозревающего страницу "... AND assignee in (currentUser())"

​​Только мне кажется, что тут всё перепутано? Метод open же должен открывать существующий файл, а new — делать новый.
Или всё правильно?

✔️ — в доке всё правильно:   open делает копию, new редактирует оригинальную картинку.
❌ — в доке ошибка: open редактирует , new делает копию.

тут к.м.к. вообще логика потеряна

)))

Павел — спец по Ruby )

Что-то не подумал заглянуть в описание канала, сразу написал Нику

Про open vs. new
Важно понимать специфику Ruby, метод new это стандартный способ создания объекта, конструктор. (Причём что ещё сильнее сбивает с толку, внутри класса будет дёрнут не new, а initialize. Ruby 🤷‍♀️)
Поэтому принято в new делать самый "голый"/простой способ инстанцирования. В случае с областью библиотеки это создание объекта-изменялки, указывающего на существующий файл. И это практически "деталь реализации".
А вот open это уже "фабричный метод". В контексте библиотеки его название имеет смысл, ибо он только "открывает" картинку, не трогая её.
Чтоб привести названия в порядок, наверное, надобно назвать new как-то иначе, чтоб не сталкиваться с примитивами языка. Скажем, modify.

Вот я бы назвал как-то вроде copy и modify

Ах да. Где мои манеры. Всем привет 👋

👋