Уведомления в баг-трекере ошибаются в обе стороны. Отправите слишком мало — и в четверг выяснится, что баг, который вы чините, ещё в понедельник переназначили. Слишком много — и к третьему дню у каждого есть почтовый фильтр и папка, которую никто не открывает. Итог в обоих случаях один. Люди перестают доверять каналу, и то единственное уведомление, которое было важно, остаётся непрочитанным.
Я только что добавил в BugDump уведомления о задачах. Отправлять их — самое простое. Основная работа ушла на то, чтобы решить, кто должен их получать и когда лучше промолчать. Ниже — правила, к которым я пришёл, и почему они такие.
Начните с одного вопроса
Для каждого уведомления спросите: сделает ли этот человек что-нибудь иначе, получив его?
Разработчик, чью задачу QA только что отметил как решённую: да, он перестанет над ней работать. Человек, который завёл баг: да, он может пойти и проверить исправление. Коллега, который месяц назад мельком заглянул в задачу: нет. Если всё равно отправить ему уведомление, это обойдётся дороже одного лишнего письма. Оно приучает его к тому, что колокольчик — это в основном шум, и следующее уведомление он читает чуть менее внимательно.
Всё, что ниже, следует из этого вопроса.
Определяйте получателей по самой задаче
Большинство трекеров отвечают на вопрос «кто об этом узнает» через наблюдателей (watchers). Нажимаете «Следить» — и получаете всё. Звучит гибко. На практике списки наблюдателей расползаются. Люди забывают подписаться на задачу, которая им важна, и остаются в тех, что перестали их интересовать ещё несколько месяцев назад. Список, который кто-то должен вести вручную, обычно устарел.
Поэтому я такой список не веду. Когда задача меняется, BugDump определяет, кто в ней участвует, по её состоянию на этот момент:
тот, кто её создал,
её исполнитель,
все, кто указан в поле типа «Участник», например Ревьюер или Ответственный за QA,
все, кто её комментировал.
Комментарий — самый сильный сигнал из четырёх. Человек, который потратил время, чтобы написать в задаче, без слов сказал вам, что хочет знать, чем всё закончится.
Поле типа «Участник» — тот же сигнал, только осознанный. Если вы хотите, чтобы дизайнер следил за багом, укажите его в поле Ревьюер. Он узнает о следующем комментарии и следующей смене статуса, а когда вы его уберёте, перестанет. Никому не нужно помнить об отписке, а человек, который уходит из проекта, сразу выпадает из всех его задач.
У этого есть цена: следить за задачей, к которой вы не имеете отношения, нельзя. Я решил, что с этим можно жить, пока кто-нибудь действительно об этом не попросит.
Не сообщайте людям о том, что они только что сделали
Звучит слишком очевидно, чтобы это записывать. Но всё становится не так очевидно, когда в дело вступают ИИ-агенты.
Когда ваш агент переносит задачу в «Готово» с вашим MCP-токеном, это ваше действие. Уведомлять вас о нём — шум: вы сами об этом попросили. Коллеги всё равно должны об этом узнать и должны видеть, что кликали не вы, поэтому в их уведомлении написано Alex Rivera через MCP.
Одно изменение — одно уведомление
Сложнее всего были случаи, когда одно решение выливается в несколько изменений.
Комментарий с упоминанием. Человек, которого упомянули через @, и так получает «Вас упомянули». Отправить ему ещё и «Новый комментарий» на тот же комментарий — это дубль, поэтому он получает только упоминание.
Серия правок при разборе. Разбор редко сводится к одной правке. Вы ставите приоритет, добавляете две метки и выбираете срок — всё за минуту, а редактор меток сохраняет на каждый клик. Если в задаче участвуют трое, это двенадцать уведомлений на то, что ощущалось как одно решение.
Поэтому изменения свойств одной задачи одним человеком учитываются раз в пять минут. Каждому получателю приходит одно «Alex Rivera изменил(а) „Приоритет“ в AS-3» на всю серию. Изменение, которое за это время сделал кто-то другой, всё равно приходит отдельным уведомлением.
Поэтому же в уведомлении указано свойство, а не значение. «Приоритет изменён на „Высокий“» становится неправдой, как только следующий клик поставит «Критический», а отправленное письмо уже не исправить. «Приоритет изменён» остаётся правдой, а текущее значение — в одном клике.
Массовое действие. Перенести 30 задач в «Готово» — тоже одно решение. Каждый получает одно уведомление с числом задач, а его кнопка открывает доску, а не отдельную задачу.
Число охватывает всё действие, а не только задачи, в которых участвует этот человек. Считать для каждого отдельно значило бы ждать, пока обработается каждая задача из пачки, и я решил, что такая точность не стоит задержки.
Что я не стал делать
Дайджест. Собирать письма в ежечасную или ежедневную сводку — звучит заботливо. На деле это задерживает одно срочное сообщение, чтобы оно пришло вместе с пятью несрочными. Я отправляю одно письмо на одно изменение, и единственное исключение — пятиминутное окно для правок свойств. Если кому-то писем слишком много, он может выключить почту и получать всё только в колокольчике.
Матрица настроек. Таблица «типы событий × каналы» выглядит основательно. Большинство людей её никогда не открывают, а те, кто открывает, обычно выключают почти всё. Правильно выбранные получатели дают больше, чем любая страница настроек.
Изменения, о которых никому не нужно знать. Правка заголовка, переключение колонки между открытой и закрытой в настройках доски, удаление задачи. Ни одно из них не проходит проверку «сделает ли человек что-то иначе», поэтому ни одно не вызывает уведомления.
Как это работает в BugDump
Уведомлений о задачах четыре: «Назначено вам», «Новый комментарий», «Статус изменён» и «Свойство изменено». Они появляются в колокольчике и приходят на почту на языке каждого получателя, на всех тарифах, включая бесплатный.
Уведомление о комментарии цитирует его начало, так что часто уже по уведомлению понятно, нужно ли открывать задачу.
Полные правила, включая всё, что уведомлений не отправляет, — в справочном центре: Уведомления о задачах: кто узнаёт об изменениях.
Читайте также
Пользовательские поля в баг-трекере: что добавить, а от чего отказаться — как отличить поле, которое окупится, от поля, которое через шесть недель будет пустым.
Метрики баг-трекинга, которые стоит считать — четыре метрики, которые показывают, успевает ли команда за багами, и еженедельный пятиминутный обзор на их основе.
Как разбирать баги быстрее: работа с клавиатуры — разбор, в котором не нужно думать быстрее: из него убрана навигация вокруг решений.