GitHub opdeler reviewtid i tre trin
GitHub udvidede den 25. september 2026 sine Copilot usage metrics med tidsmål for review af pull requests. En pull request er et forslag til en kodeændring; de nye mål gør det lettere at undersøge, hvor forløbet bruger tid.
Fra klar til review til sammenfletning
Rapporterne opdeler tiden i klar til første review, første til sidste review og sidste review til merge. Hvert trin har median og 90-percentil. Tallene henføres til den dag, kodeændringen blev sammenflettet.
Kun kvalificerende, menneskeskabte pull requests med review fra en anden person indgår. Botreviews tælles ikke som menneskelige reviews. Data bygges fremad uden historisk tilbagefyldning; forslag klar til review før 21. september udelades fra det nye afsnit. Adgang kræver relevante rettigheder og aktiveret metrics-politik.
Find det trin, der kræver en beslutning
Min anbefaling er at undersøge, om arbejdet venter på en første reaktion, gennemgang af ændringer eller den endelige integration. De situationer kan have forskellige ansvarlige og forskellige løsninger.
Et tænkt team kan have hurtige reviews, men vente på en fælles releasebeslutning. Mere reviewkapacitet vil ikke nødvendigvis ændre den sidste del af forløbet.
Hold målingens grænser synlige
Notér, hvilke sager der er omfattet af den valgte visning, før perioder sammenlignes. En tidlig rapport efter en lancering kan have få observationer. Den bør ikke få samme vægt som en længere, stabil serie.
Se også på åbne sager separat. En rapport over afsluttede forløb fortæller ikke alene, hvor meget arbejde der stadig står og venter.
Brug tallene til at vælge en lille ændring
Gennemgå nogle konkrete forløb med dem, der udfører arbejdet. Aftal derefter en afgrænset ændring, eksempelvis tydeligere ansvar ved første review, og følg op med samme definitioner.
Tidsmålinger kan pege på et undersøgelsesområde. De dokumenterer ikke i sig selv kodekvalitet, individuelle præstationer eller en effekt af AI.