GitHub расширил отчеты Copilot Usage Metrics на уровне репозиториев: в суточных строках repos-1-day появился массив pull_request_review_times. Он показывает, сколько времени смерженные пул-реквесты проводят на трех последовательных этапах ревью.
Обновление анонсировано GitHub 25 сентября 2026 года. Для каждого этапа API возвращает продолжительность в минутах в виде двух агрегатов — медианы и 90-го перцентиля. Существующие поля pull_requests при этом не меняются.
Для инженерных руководителей это способ выяснить, где именно PR задерживается: до первой реакции ревьюера, во время цикла правок или уже после финальной проверки. Однако новые показатели сами по себе не доказывают влияние Copilot на скорость разработки: они описывают движение пул-реквестов через процесс ревью, а не причины задержек.
Какие интервалы появились в отчете
Новый массив делит процесс на три интервала:
От момента, когда пул-реквест получил статус ready for review, до первого ревью.
От первого ревью до финального ревью.
3. От финального ревью до мержа.
Речь идет об агрегированных показателях для строки репозитория за день, а не о подробной временной шкале каждого отдельного пул-реквеста. В массиве указываются медиана и p90 продолжительности каждого этапа.
Медиана помогает оценить типичный сценарий: половина учтенных наблюдений находится ниже этого значения, половина — выше. 90-й перцентиль показывает границу, в которую укладывается большая часть результатов, и позволяет заметить редкие затяжные случаи. Если медиана остается стабильной, а p90 растет, отдельные PR, вероятно, проводят в ожидании заметно больше времени, чем основная масса.
GitHub уточняет, что длительности выражаются в минутах и относятся к дню, когда пул-реквест был смержен. Поэтому суточная строка не обязательно отражает работу, выполненную только за эти сутки. PR мог перейти в статус готового к ревью раньше, а весь накопленный интервал будет учтен в дате мержа.
Общее устройство REST API GitHub и правила работы с его ресурсами описаны в официальной документации платформы. Контекст по функциям и корпоративному развертыванию Copilot доступен в разделе документации GitHub Copilot.
Как читать три стадии задержки
Каждый интервал указывает на отдельную часть процесса, поэтому одинаковое общее время до мержа может требовать разных управленческих решений.
Долгий период до первого ревью может означать, что у команды нет понятного назначения ответственных, ревьюеры перегружены либо уведомления о новых PR теряются. На такую проблему обычно реагируют правилами автоматического назначения, очередями ревью или внутренними нормативами времени первой реакции.
Большой интервал между первым и финальным ревью связан с самим циклом проверки. Среди возможных причин — крупный размер изменений, несколько раундов исправлений, ожидание ответа автора или необходимость привлечь специалиста по конкретной части системы. Одной метрики недостаточно, чтобы выбрать объяснение: для диагностики придется сопоставить ее с размером PR, числом комментариев, повторными запросами изменений и результатами проверок.
Задержка между финальным ревью и мержем указывает уже на этап после завершения проверки. Здесь PR может ожидать обязательные проверки, окно релиза, обновление ветки, ручное действие владельца репозитория или выполнение внутренних правил. Сам термин «финальное ревью» не следует автоматически приравнивать к полной готовности к развертыванию: в конкретном репозитории могут действовать дополнительные ограничения.
Почему медианы недостаточно
Среднее или медиана могут скрывать небольшую группу пул-реквестов, которые надолго застревают в очереди. Поэтому GitHub выводит рядом p90. Сравнение этих двух значений помогает отличить системную задержку от выбросов.
Если высоки оба показателя, проблема, вероятно, затрагивает значительную часть потока. Если медиана невелика, а p90 значительно выше, стоит изучить самые медленные PR отдельно. Это могут быть изменения в критичных компонентах, задачи с большим количеством зависимостей или пул-реквесты без активного владельца.
Сравнивать репозитории только по абсолютным значениям рискованно. Небольшое прикладное хранилище, монорепозиторий и проект с обязательным аудитом безопасности работают по разным правилам. Полезнее отслеживать динамику одного репозитория и отмечать даты изменений процесса: введение автоматического назначения ревьюеров, новых branch protection rules или дополнительных CI-проверок.
При малом числе смерженных PR суточные перцентили также могут быть нестабильными. В анонсе GitHub не приводятся минимальный размер выборки, метод обработки дней без мержа и правила интерпретации неполных этапов. Эти детали нужно сверять с актуальной схемой ответа API перед построением алертов.
Метрика не измеряет эффективность Copilot напрямую
Поле добавлено в отчеты Copilot Usage Metrics, однако разбивка времени ревью не устанавливает причинную связь между использованием ассистента и скоростью мержа. Быстрое прохождение PR может зависеть от размера команды, сложности изменений, правил репозитория, часовых поясов и стабильности CI.
Поэтому показатель лучше использовать как операционную метрику, а не как самостоятельную оценку продуктивности разработчиков или окупаемости Copilot. Для анализа влияния инструмента потребуются дополнительные данные: интенсивность его использования, характеристики репозиториев, объем изменений и сопоставимые периоды до и после внедрения.
Новая разбивка также не заменяет события отдельных пул-реквестов. Интервал от первого до финального ревью объединяет весь цикл обсуждений и исправлений. По агрегату нельзя узнать, сколько было раундов проверки, кто запросил изменения и сколько времени заняла работа автора в сравнении с ожиданием ревьюера. Для такого анализа понадобятся данные о конкретных PR и событиях ревью. Модель работы с пул-реквестами GitHub отдельно описывает в документации по совместной работе над изменениями.
Что проверить перед добавлением метрики в дашборд
Командам, которые уже выгружают строки repos-1-day, сначала стоит проверить фактическую схему ответа и наличие pull_request_review_times в своем отчете. Интеграция должна корректно обрабатывать отсутствие поля, пустые значения и дни без смерженных пул-реквестов.
Следующий шаг — вывести медиану и p90 отдельно для каждой стадии, не складывая их сразу в один показатель. Так будет видно, какой участок процесса изменился. Для оценки тренда надежнее использовать более длинное окно наблюдения, сохраняя возможность перейти от аномального дня к исходным PR.
Перед настройкой пороговых уведомлений полезно проверить:
- к какой дате относятся значения и совпадает ли она с датой мержа;
- сколько пул-реквестов вошло в дневную выборку;
- не изменились ли одновременно правила ревью или обязательные проверки;
- можно ли связать агрегированную аномалию с конкретными PR;
- не используются ли показатели для сравнения несопоставимых репозиториев или команд.
GitHub пока сообщил именно о расширении API и не представил независимой оценки того, как новая детализация влияет на скорость разработки. Практическая ценность обновления будет зависеть от качества локального контекста: без числа наблюдений и данных по отдельным PR даже точные медиана и p90 показывают место задержки, но не объясняют ее причину.