Copilot Usage Metrics API: PR İnceleme Süresi Kırılımı
GitHub’ın kurumsal ve organizasyon düzeyindeki repository-level Copilot usage metrics raporları artık bir pull request’in inceleme sürecinde nerede beklediğini de gösteriyor. repos-1-day satırlarına eklenen yeni pull_request_review_times dizisi, “PR’lar neden geç merge ediliyor?” sorusunu üç ayrı aşamanın medyan ve 90. yüzdelik değerleriyle yanıtlıyor.
Yeni alan ne dönduruyor?
pull_request_review_times dizisindeki her kayıtta şu alanlar var:
authored_byvereviewed_by: Kayda giren pull request’leri kimin açtığı ve kimin incelediği. Bu sürümde ikisi dehumandeğerini alıyor.total_merged: O gün ilgili repository’de merge edilen, kriterlere uyan pull request sayısı.median_minutes_ready_to_first_reviewvep90_minutes_ready_to_first_review: PR’ın incelemeye hazır hale gelmesinden ilk incelemeye kadar geçen süre.median_minutes_first_to_final_reviewvep90_minutes_first_to_final_review: İlk inceleme ile son inceleme arasındaki süre.median_minutes_final_review_to_mergevep90_minutes_final_review_to_merge: Son incelemeden merge’e kadar geçen süre.
Süreler dakika cinsinden veriliyor ve pull request’in merge edildiği güne yazılıyor. Mevcut pull_requests alanlarında bir değişiklik yok, yeni veri bunların yanına ekleniyor.
Beklemenin hangi aşamada geçtiği
Ekipler bir pull request’in merge edilmesinin uzun sürdüğünü bugüne kadar da görebiliyordu, ama o sürenin nerede harcandığını göremiyordu. Üç aşamaya ayrılmış bekleme, PR’ın kimsenin bakmamasını mı beklediğini, inceleyenler arasındaki gidip gelmede mi takıldığını, yoksa onaylanmış halde merge edilmeyi mi beklediğini ortaya koyuyor.
Üçünün çözümü de farklı: birincisi atama ve gözden geçiren kapasitesiyle, ikincisi inceleme kalitesi ve PR boyutuyla, üçüncüsü merge disiplini ve otomasyonla ilgili. Medyanın yanında 90. yüzdelik değer de bulunduğu için gecikmenin genel bir yavaşlıktan mı yoksa birkaç aşırı yavaş pull request’ten mi kaynaklandığı ayırt edilebiliyor.
Neyin sayıldığına dikkat
Ölçümün kapsamı dar ve net tanımlanmış:
- Yalnızca bir kişinin açtığı ve en az bir başka kişinin incelediği pull request’ler sayılıyor.
- Sadece insan incelemeleri zamanlanıyor. Copilot code review, diğer bot incelemeleri ve PR sahibinin kendi incelemeleri yok sayılıyor. Hem bir kişinin hem Copilot code review’un incelediği bir PR yine kapsama giriyor.
- Bu yüzden
pull_request_review_times[].total_mergeddeğeri genelliklepull_requests.total_mergeddeğerinden düşük kalıyor; ikincisi hiç inceleme almadan merge edilen pull request’leri de sayıyor.
İki sayacı karşılaştırırken bu farkı hesaba katmak gerekiyor. Aradaki fark tek başına “incelemesiz merge” hacmi hakkında fikir verebilir, ama yorumu her ekibin kendi süreç kurallarına bağlı.
Geriye dönük veri yok
Veri yayın tarihinden itibaren ileriye doğru birikiyor, geçmişe dönük doldurma yapılmıyor. İlk günlerin verisi bu nedenle seyrek olacak. 21 Eylül 2026 tarihinden önce incelemeye hazır hale gelmiş pull request’ler bu bölümün dışında kalıyor, pull_requests.total_merged sayacına ise dahil edilmeye devam ediyor.
Boş günlerin nasıl temsil edildiği de önemli bir ayrıntı. Kriterlere uyan hiçbir pull request’in merge edilmediği günlerde dizi 0 değil, boş dizi ([]) olarak dönüyor; raporu işleyen script veya dashboard’larınızın bunu “sıfır süre” olarak yorumlamaması için kontrol eklemeniz gerekiyor. Yalnızca tek bir inceleme alan pull request’lerde ise ilk incelemeden son incelemeye kadar geçen aşama 0 olarak raporlanıyor.
Erişim gereksinimleri
Raporlara şu roller erişebiliyor:
- Enterprise sahipleri ve billing manager’lar
- Organizasyon sahipleri
View Copilot Metricsiznini veren özel organizasyon veya enterprise rollerine sahip kullanıcılar
Bunun yanında Copilot usage metrics politikasının etkin olması gerekiyor. Yeni alan hem enterprise hem de organizasyon düzeyindeki repos-1-day raporlarında yer alıyor.
Pratikte nasıl kullanılır?
Alanı anlamlı kılan şey, üç aşamanın ayrı ayrı izlenebilmesi. İlk incelemeye kadar geçen sürenin medyanı düşük ama p90 değeri yüksekse, PR’ların çoğu hızlı ele alınıyor, belirli bir azınlık ise uzun süre sahipsiz kalıyor demektir. Son incelemeden merge’e kadar geçen sürenin yüksek olması ise inceleme kapasitesiyle değil, merge sonrası adımlarla ilgili bir sinyal verir.
Veri günlük çözünürlükte ve merge gününe atfedilmiş şekilde geldiği için kısa dönemli dalgalanmalar yerine haftalık veya aylık eğilimleri takip etmek daha güvenilir bir okuma sağlıyor. Alanların tam şeması ve istek örnekleri resmi API dokümantasyonunda.
Kaynaklar ve İleri Okuma
- Usage metrics API adds pull request review stages – GitHub Changelog
- Copilot usage metrics API dokümantasyonu
- Repository-level GitHub Copilot usage metrics genel kullanıma açıldı
- Copilot Usage Metrics API’ye Ajan Bazlı Aktivite Kırılımı
- Copilot Usage Metrics API ile Kullanıcı Bazlı AI Kredisi
- Copilot Code Review Metrikleri: Aktif mi Pasif mi?
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder