Ngày 25/9/2026, GitHub công bố trên changelog rằng báo cáo usage metrics của GitHub Copilot ở cấp tổ chức và doanh nghiệp nay chia thời gian review pull request thành từng giai đoạn. Một mảng dữ liệu mới tên pull_request_review_times xuất hiện trên mỗi dòng repos-1-day. Đây là phần bổ sung cho bộ báo cáo đo mức dùng Copilot mà GitHub đã mở rộng ở cấp kho mã nguồn trước đó.
Với đội phát triển ở Việt Nam đang dùng GitHub và GitHub Copilot, thay đổi này nằm ở tầng số liệu quản trị. Nó không thêm nút bấm cho lập trình viên, nhưng giúp người quản lý biết thời gian chờ review đang tắc ở khâu nào, từ đó xử lý đúng chỗ thay vì phỏng đoán.
Có gì mới trong báo cáo usage metrics
Theo thông báo, các báo cáo usage metrics ở cấp doanh nghiệp và tổ chức giờ phân tích được thời gian pull request nằm ở từng chặng review. Mảng pull_request_review_times được thêm vào mỗi dòng repos-1-day, chạy song song với các trường cũ. GitHub nêu rõ các trường pull_requests hiện có không đổi, nên báo cáo cũ vẫn dùng bình thường.
Mỗi mục trong mảng mới gồm vài thành phần quen thuộc. Đó là authored_by và reviewed_by để biết ai mở và ai review pull request, trong bản này cả hai đều là human. Đó là total_merged, tức số pull request đủ điều kiện được merge trong ngày. Và đó là các cặp số trung vị với phân vị 90 cho từng giai đoạn.
Ba giai đoạn review được đo thế nào
Thời gian được chia thành ba chặng. Chặng một đo từ lúc pull request sẵn sàng review tới lần review đầu tiên. Chặng hai đo từ lần review đầu tới lần review cuối. Chặng ba đo từ lần review cuối tới lúc merge. Mỗi chặng có hai con số: trung vị và phân vị 90.
Cách chia này quan trọng hơn vẻ ngoài của nó. Trước đây đội chỉ biết một pull request mất bao lâu để merge, nhưng không biết thời gian đó nằm ở đâu. Một pull request chờ ba ngày có thể vì chưa ai ngó tới, cũng có thể vì đang tranh luận qua lại giữa các reviewer, hoặc vì đã duyệt xong mà nằm chờ merge. Ba nguyên nhân đó cần ba cách sửa khác nhau.
Đơn vị thời gian tính bằng phút, và dữ liệu được gán cho ngày pull request được merge, không phải ngày nó được tạo. Đây là chi tiết dễ bỏ sót khi đọc số, vì một pull request mở từ tuần trước vẫn có thể rơi vào báo cáo của ngày hôm nay.
Vì sao chia nhỏ thời gian lại hữu ích
Con số phân vị 90 là phần đáng chú ý. Nếu trung vị thấp mà phân vị 90 cao, nghĩa là phần lớn pull request trôi khá nhanh, nhưng một nhóm nhỏ kéo dài bất thường. Đó thường là dấu hiệu vài pull request phức tạp hoặc vài người đang quá tải. Nhìn trung vị đơn thuần sẽ che mất nhóm này.
Với đội đông người, ba giai đoạn giúp tách vấn đề con người khỏi vấn đề quy trình. Nếu chặng một dài, vấn đề nằm ở việc phân công người review hoặc thiếu người có chuyên môn. Nếu chặng hai dài, vấn đề nằm ở thảo luận và vòng sửa code. Nếu chặng ba dài, vấn đề nằm ở bước merge và phát hành. Mỗi kết luận dẫn tới một hành động khác nhau.
Ai xem được dữ liệu này
GitHub giới hạn quyền truy cập khá rõ. Người xem được gồm chủ doanh nghiệp, người quản lý thanh toán, chủ tổ chức, và người được gán vai trò tùy chỉnh ở cấp tổ chức hoặc doanh nghiệp có quyền View Copilot Metrics. Ngoài ra chính sách Copilot usage metrics phải được bật thì báo cáo mới có dữ liệu.
Điều này có nghĩa phần lớn lập trình viên sẽ không thấy trực tiếp mảng dữ liệu mới. Người dùng phổ thông của Copilot vẫn làm việc như cũ, còn quản trị viên và trưởng nhóm kỹ thuật là nhóm khai thác số liệu. Nếu công ty bạn chưa bật chính sách usage metrics, cần bật trước khi bàn tới việc đọc báo cáo.
Những điểm cần lưu ý khi đọc số
GitHub nêu vài giới hạn nên biết để không hiểu sai. Báo cáo chỉ tính pull request do một người mở và được ít nhất một người khác review. Chỉ review của con người mới được tính thời gian, còn review từ Copilot code review, các bot khác và chính tác giả bị bỏ qua. Vì vậy total_merged trong mảng mới thường thấp hơn total_merged của trường pull_requests, vốn tính cả pull request merge mà không cần review nào.
Dữ liệu cũng không hồi tố. Nó chạy tiến từ ngày phát hành, nên những ngày đầu sẽ mỏng. Các pull request sẵn sàng review trước ngày 21/9/2026 không nằm trong phần này, dù vẫn được tính vào tổng pull request merge. Ngoài ra, ngày không có pull request đủ điều kiện sẽ trả về mảng rỗng chứ không phải số 0, và chặng từ review đầu tới review cuối bằng 0 khi pull request chỉ có một lần review.
Ba lưu ý này nghe khô khan nhưng ảnh hưởng trực tiếp tới cách đọc biểu đồ. Nếu bạn thấy dữ liệu vài tuần đầu lệch thực tế, rất có thể đó là do không hồi tố chứ không phải do quy trình thay đổi.
Nên làm gì với bộ số liệu này
Nếu đội bạn đã dùng Copilot ở quy mô tổ chức, hãy kiểm tra xem ai đang có quyền xem usage metrics và chính sách đã bật chưa. Sau đó chờ dữ liệu tích đủ vài tuần rồi mới đặt ra mục tiêu rút ngắn từng chặng. Vội vàng kết luận từ vài ngày dữ liệu mỏng sẽ dẫn tới quyết định sai.
Khi có số, nên gắn nó với thay đổi cụ thể: phân công người review trực, giới hạn số pull request mở cùng lúc, hoặc đặt quy tắc merge trong ngày. Bản thân con số không sửa được quy trình, nhưng nó chỉ ra chỗ cần sửa. Bạn có thể đọc thêm tài liệu Copilot usage metrics API trên trang GitHub để biết cách lấy dữ liệu.
Thông tin về trường dữ liệu và điều kiện truy cập có thể được GitHub điều chỉnh, nên hãy kiểm tra lại tại thông báo changelog của GitHub trước khi xây báo cáo nội bộ. Nếu đội còn cân nhắc công cụ quản lý mã nguồn, xem thêm bài về GitHub để nắm các tính năng liên quan.
