Как ревьюить pull request и не отпугнуть контрибьютора: ярлык против разбора

Пяти секунд хватает, чтобы отбить у человека желание присылать что-либо в открытый проект. Столько занимает комментарий вида «похоже, это сгенерировал ИИ, не будем тратить время на ерунду». Формально ревьюер ничего не нарушил: обязательств перед автором у него нет, лишних рук у проекта тоже, объясняться он не должен. Беда в том, что та же фраза одинаково хорошо работает и на том, кто второй день учится делать коммиты из терминала.

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

Что случилось

В конце февраля 2026 года контрибьютор открыл merge request в проекте, который в исходном разборе назван SkyRelay. Это открытая сеть волонтёрских наземных станций спутниковой связи — название изменено, потому что люди, поддерживающие проект, делают полезную работу и не заслуживают публичной порки. Запрос ускорял одну из самых нагруженных страниц.

Мейнтейнер пометил его как черновик. Комментарий: быстрая проверка показала признаки ИИ-генерации, заявка откладывается, «чтобы не тратить время ревью на ИИ-ерунду».

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

На следующий день автор закрыл merge request сам. Заодно закрыл второй, куда меньший фикс, открытый в тот же день и не вызвавший ни у кого вопросов. Больше он в проект ничего не присылал.

Что на самом деле было в изменении

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

Шума вокруг тоже хватало:

• правило стиля кода отключили вместо того, чтобы подогнать новый код под него;
• в lock-файле появились записи, к изменению не относящиеся;
• пайплайн упал;
• способ загрузки страницы поменяли, не согласовав подход в issue.

Всё это заслуживает комментария на ревью. И ничего необычного в этом нет — так выглядит merge request человека, который работает быстро, у себя на машине и никого не спросил заранее. «Это надо доработать» — нормальная фраза. «Это ерунда» — совсем другая.

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

У моего запроса тоже были признаки

Этот merge request автор разбора узнал, потому что присылал похожий.

На той же неделе он заканчивал правку документации в GitLab. Учился работать с Git из командной строки и вёл три задачи параллельно. Изменения из соседних задач раз за разом просачивались в текущий merge request. Из терминала этого не видно — только в диффе, уже после пуша. Так вышло три пуша подряд.

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

При беглом взгляде признаки были и там: посторонние файлы, форматированный шум, грязная история. Ревьюер посмотрел мимо них. Остался вежливым, дождался финальной версии, хотя терпение его, судя по всему, истончилось — и злиться на это глупо. В итоге автор сам закрыл запрос и открыл новый, только с той правкой, которую и собирался внести. Через несколько дней её смерджили, в GitLab 18.10 изменение попало.

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

Когда дверь остаётся открытой

Несколькими неделями позже случился обратный опыт, и в куда более сложном месте. Автор добавлял поддержку Kroki в провайдер GitLab для Terraform, чтобы команды, управляющие GitLab как кодом, могли включать рендеринг диаграмм конфигом, а не руками. Провайдер написан на Go, в котором автор ещё осваивался, и понадобилось три merge request, чтобы всё получилось.

Самым трудным оказался не код. Ноутбук на тот момент — 8 ГБ оперативной памяти. Docker его ронял, WSL не запускался, а документацию в проекте положено не писать руками, а генерировать инструментом. Попытка написать вручную привела к падению пайплайна, что логично.

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

Сделали и то и другое. Один мейнтейнер объяснил, что для шага с документацией Docker вообще не нужен, и указал команду, которую положено выполнять до открытия запроса. Второй прогнал её сам, запушил результат и посоветовал на будущее удалённое окружение для разработки. Позже, когда диффы стали выглядеть странно, попросили прогнать форматтер Go — потому что табы и пробелы перемешались. Форматирование, опять.

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

Аккуратно там не было ничего. Три попытки, красный пайплайн, перемешанное форматирование и честное признание, что инструменты проекта не запускаются на своей машине. При беглом взгляде признаков тут больше, чем в двух других историях. Но было и другое: прозрачность в обе стороны. Автор честно сказал о своих ограничениях, мейнтейнеры честно сказали, что нужно доделать.

Цепочка последствий в одной заявке

Быстрая проверка подменяет ревью. Мейнтейнеров заваливает потоком, и скорый фильтр — способ самозащиты. Но быстрая проверка — это классификатор, а у любого классификатора есть ложные срабатывания. Признаки, которые он ловит (шум, посторонние файлы, упавший пайплайн), ровно так же выглядят у человека, который учится, спешит, работает на слабом железе или не ожидал, что инструмент сам поменяет строки.

Метка достаётся человеку, а не коду. «Надо доработать» говорит, что исправлять. «ИИ-ерунда» говорит, что ревьюер думает о вас. Действовать можно только по первому.

Человек уходит молча. Никто не спорил и не жаловался. Заявку просто закрыли, и нигде не записано, что рабочий фикс вышел за дверь.

Проблема остаётся и позже стоит дороже. В октябре 2026 года, семь месяцев спустя, другой мейнтейнер открыл новый merge request про ту же медленную загрузку. Работа аккуратная, с замерами. Одна из причин, которые в ней названы, — тот самый запрос на каждый спутник. А часть, пока не покрытая, указана как следующий шаг и измерена в более чем девять секунд на данных продакшн-размера. В закрытой заявке ответ на этот запрос уже лежал.

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

Ни на одном шаге этой цепочки никому не нужно было злых намерений. Каждый шаг по отдельности выглядит разумно. Ровно поэтому их стоит записывать.

«Нет ресурсов» — это полный ответ

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

Поэтому просьба маленькая: если ресурсов на ревью нет — так и сказать. Это честно. И это законченный ответ.

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

Такой ответ занимает те же секунды, что и метка. Он сохраняет и человека, и фикс. В комментарии SkyRelay, к слову, вторая половина была почти такой: если бы три просьбы составляли весь комментарий, разбора бы не понадобилось.

Политика работает лучше ярлыка

Позже SkyRelay опубликовал политику по ИИ для контрибьюторов. Там прямо сказано: проконтролировать, как именно написан merge request, проект не может, поэтому и не пытается. ИИ-ассистированные контрибуции разрешены — при условии, что человек понимает изменение и берёт за него полную ответственность. Про повторяющиеся некачественные присылки формулировка жёсткая, и это разумно.

Это правильный ответ. Вопрос смещается с «как это написано» на «понимаете ли вы это и готовы ли отвечать». На второй вопрос человек как раз может ответить.

Что даёт разбор

Ревью говорит правду о коде. Метка — о вас.

Для тех, кто учится так же — самоучкой, вне найма, выстраивая собственную практику на виду, — первые merge request почти всегда шумные. Этот шум и есть то, как выглядит обучение снаружи. Если первым ответом на него идёт метка, первыми уходят те, кому этот опыт нужнее всего.

Что ревьюер действительно может проверить: работает ли изменение и способен ли автор объяснить, что и зачем он поменял. Был ли замешан инструмент — из диффа не видно никому, и это никогда не было самым полезным вопросом.

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