Как остановить спам пул-реквестами в открытом репозитории: 4 барьера и воронка для новичков

Мусорные пул-реквесты приходят из-за слишком короткого пути до кнопки «Create pull request». Лечится это настройкой маршрута: защищённая ветка, обязательное ревью, владельцы файлов и первый контакт вне пул-реквеста.

Дальше — как собрать такую схему на GitHub и GitLab и что написать в правилах для контрибьюторов, чтобы их действительно прочитали.

Почему спам вообще доходит до мейнтейнера

Настройка по умолчанию выглядит так: fork, правка, PR. Любой случайный человек попадает в ту же очередь на ревью, что и серьёзный контрибьютор с продуманным патчем. Экономика простая: отправить мусор дёшево, разобрать его — дорого. Пока это соотношение не перевернуть, фильтры не спасут.

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

Четыре контроля, которые снимают основную часть шума

Защита главной ветки

Защитите main (или master). Требуйте прохождения проверок CI и минимум одного одобряющего ревью до мержа. Сам поток мусорных PR это не остановит, но он перестанет превращаться в работу: без одобрения ветка никуда не уедет. В GitHub это protected branches с обязательными проверками и ревью, в GitLab — approval rules и required approvals для merge request.

CODEOWNERS для чувствительных путей

Файлы, которые чаще всего притягивают случайные правки, стоит закрепить за владельцами через CODEOWNERS. GitHub тогда сам подставляет ревьюеров, GitLab умеет назначать code owners как approvers. Задача — не усложнить жизнь своим, а сделать сигнал очевидным: вот человек, который решает по этому пути. Сам по себе CODEOWNERS спам не отфильтрует, он только маршрутизирует ревью, и работает в связке с защитой ветки.

Разные воронки для своих и для новых имён

Основная часть мусора приходит от аккаунтов без истории. Значит, первый контакт с проектом должен быть дешёвым для вас и не равным пул-реквесту. Рабочая схема: сначала issue или discussion, там — зачем нужно изменение, какой сценарий ломается, что уже пробовали. PR принимается только после того, как мейнтейнер подтвердил объём. GitHub прямо допускает ограничение доступа к пул-реквестам и даже полное их отключение, если abuse стал проблемой.

Закрытие в одну фразу

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

Шаблон issue как разгрузочная полоса

Мусорный PR часто появляется потому, что отправителю некуда было пойти с вопросом. Шаблон issue решает половину задачи: он просит описание бага, мотивацию, скриншот, ожидаемое поведение и шаги воспроизведения. Когда эта форма заполняется быстрее, чем собирается ветка с правками, случайные люди оседают там, а не в очереди на мерж. Разбирать issue всё равно придётся, но это заметно дешевле, чем распаковывать чужой невнятный бранч.

Что писать в CONTRIBUTING.md

Политику держите в своём репозитории, а не в почте или третьем сервисе. Конкретика важнее объёма. Один абзац — какие изменения вы ждёте: скажем, багфиксы с тестом и правки документации по конкретным разделам. Второй — что закрывается без обсуждения: косметические переименования по всему проекту, форматирование «на глаз», переписывание архитектуры одним коммитом.

И одна строка про минимальный сигнал: без ссылки на issue или подтверждённого объёма PR не рассматривается. Эту фразу имеет смысл продублировать в шаблонах issue и pull request — иначе её просто не увидят.

Ошибки, которые ломают всю схему

• Спорить с каждым мусорным PR. Реагировать подробно — значит показывать, что вход дешёвый, а отклик гарантирован.
• Путать открытость с безлимитным доступом. Открытый исходный код не требует, чтобы любой посетитель мог предложить мерж в любой файл.
• Раздавать права на запись «на всякий случай». Чем больше аккаунтов могут пушить ветки, одобрять и править правила, тем больше мест, где шум превращается в очередь на мерж.
• Держать пустую форму issue. Если заполнить форму сложнее, чем открыть PR, поток пойдёт в PR.
• Пытаться перемодерировать входящий поток вместо сужения входного отверстия. Это бесконечная гонка.

Если спам не прекращается

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

Чек-лист для небольшого репозитория

1. Защитить main: обязательные проверки CI плюс одно одобряющее ревью.
2. Добавить CODEOWNERS для тех директорий, куда чаще всего лезут со стороны.
3. Настроить шаблон issue: мотивация, шаги воспроизведения, ожидаемое поведение.
4. Проверить права: мержить и править правила должен минимальный круг людей.
5. Написать короткую политику и продублировать её в шаблонах.
6. Проверить, что путь «issue → подтверждение → PR» короче, чем «форк → правка → PR». Если нет, шаблон не сработает.

Частые сомнения

Одного ревью хватит? Для небольшого репозитория — да, если рядом есть проходящие проверки. Планку поднимают точечно, на чувствительных путях, через CODEOWNERS или более строгие правила ветки.

Не отпугнёт ли это нормальных контрибьюторов? Отпугнуть может. Любой барьер добавляет трения и тем, кто пришёл всерьёз. Поэтому настройка должна быть узкой, а не абсолютной: защищённая ветка, одно ревью, владельцы файлов, внятный шаблон issue. Если после этого нужно больше контроля, GitHub и GitLab дают более строгие правила одобрения и ограничения на уровне веток.

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