GitHub начал учитывать черновые pull request в лимитах на открытые PR

GitHub 8 октября 2026 года расширил настройки лимитов на pull request: теперь их можно сконфигурировать так, чтобы в счёт шли и черновые PR (draft). Анонс в GitHub Changelog короткий, а мотив назван без обиняков: мейнтейнеры видят в репозиториях всё больше низкокачественных контрибуций и нуждаются в лучших способах с ними работать.

Что именно изменилось

Лимиты на pull request позволяют владельцам репозиториев ограничивать количество одновременно открытых PR. Судя по формулировке «теперь можно также включать черновики», до этого draft-запросы в такие ограничения не входили. Для автора, который хотел обойти лимит, это была готовая лазейка. Достаточно открывать заготовки в статусе draft и копить их сколько угодно.

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

Откуда берётся шум

Поток слабых контрибуций в open source давно стал отдельной проблемой. Часть таких запросов появляется из-за массовых правок ради статистики или «портфолио». Всё больше их генерируют кодовые ассистенты и агенты, которые умеют открывать PR быстрее, чем человек способен прочитать описание. GitHub в анонсе причины не расшифровывает, но контекст отрасли очевиден: стоимость создания PR упала почти до нуля, а стоимость ревью осталась прежней и целиком лежит на мейнтейнере.

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

Что известно по параметрам

• Дата публикации: 8 октября 2026 года, раздел GitHub Changelog.
• Суть: draft pull request можно включить в подсчёт лимитов на PR.
• Тип настройки: опциональная, управляется на стороне мейнтейнеров.
• Заявленная цель: снизить нагрузку от низкокачественных контрибуций.
• Не раскрыто в анонсе: конкретные пороги, правила подсчёта по авторам и поведение уже открытых драфтов при включении опции.

Практические выводы

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

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

Изменение небольшое и не решает проблему качества: лимит ограничивает объём, а не содержание. Но как один из слоёв защиты вместе с шаблонами PR, обязательными проверками и ограничением круга авторов он работает. Точные механики подсчёта лучше сверить с документацией GitHub: в самом анонсе деталей мало.