спасибо

Я пользуюсь инструментом todoist от их компании и их статья https://doist.com/blog/betting-against-slack/ подтолкнула перейти на иной тип коммуникации в ином инструменте. Крутые ребята, знают, о чём говорят.

огонь!

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

Как впечатления? Сложно внедрить было?

Я не могу сказать, что мы пользуемся чем-то типа твиста. Мы перешли на microsoft teams. Основная причина была - хотелось уменьшить кол-во обработки лишней информации, также, как сказано в статье, старались уйти от постоянного реал-тайм общения.

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

Делаем через gitlab action в слак да,  постэкшон после публикационного пайплайна, от имени бота по имени Эрнест (у него Хемингуэй на аватарке))

а как конфигурируете Эрнеста?

Или он на всё реагирует одинаково?

В том числе эта фича, но идея-то гораздо старше фичи.

Тут могут быть как минимум два повода и категории людей для уведомления:
1. Предлагается изменение, уведомляем ревьюеров.
2. Изменение опубликовано, уведомляем получателей информации

Ну и если автор и ревьюеры — люди технические и могут в гит/гитхаб/гитлаб, то первая задача сводится к задаче про изменения в коде.
Мне нравится, как это у нас в Плеске сделано: на каждый пуллреквест бот создаёт канал в слаке и приглашает туда автора и ревьюеров. Потом тот же бот в этот чат дублирует все комментарии из ПР. При этом никто лично не меншнится, но в непрочитанных видно новый чат.
Как ревьюер я просто смотрю в слак, когда мне удобно, замечаю этот чат и захожу поревьюить. Если ПР совсем срочный — а это бывает крайне редко, если там тесты упали — то мне пишут в личку.

Ого

А по второй категории, имхо, лучше работает пуш. Просто куда-то публикуем журнал изменений. А сильно технические читатели внутри компании идут смотреть git log.

А, ну и когда ПР замержили, бот говорит "отличная работа, всем спасибо" и архивирует чат.

Эволюция и маркетинговый отбор.

В эволюции видов есть половой отбор. Это такая штука, из-за которой появляются странные и даже вредные для выживания признаки вроде огромного павлиньего хвоста.

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

The SwaggerHub team
Steph from SmartBear
Patrick Londa from SmartBear

Кажется, пройдет ещё пара месяцев и следующий заголовок будет какой-то такой:

Alonzo the Magnificent from S...

Но я это письмо уже не получу, потому что только что случайно отписался. Просто не понял, от кого рассылка. Подумал, что очередной спам.

При всём уважении к конкретным людям, которые пишут рассылки о продуктах, я не знаю этих людей и не хочу знать. И сам не хочу чтобы меня лично знали читатели документации, которую я пишу. Продукт важнее, компания на втором месте, а для личных знакомств пусть будут личные блоги.

Ох, какой интересный спор мимо меня прошел... Было дело, устраивали мы схему с controlled documents, чтобы автоматически ревью и аппрув процессов/процедур/постмортемов/кастомер коммюнике делать. Примерно так это и работало - у каждого документа есть RACI матрица, по которой для I отправлялось уведомление в слак, для R делалась ещё и таска в джире, которую мог закрыть только аппрувер, и так далее

Когда вынесли всю рутину за скобки, то количество выходов за SLA для постмортемов сократилось на 78%

С процессами такой спешки нет, но по ним зато SLA по ревью и аппруву почти вдвое улучшился за счёт того, что ключевые SLO типа времени отклика для заинтересованных лиц уменьшилось

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

Все это самым очевидным образом пересчитывается в деньги из сэкономленных человеко-часов и незафейленных SLA