Sankey-diagram over pull request-review: fra størrelse til merge
Se, hvordan pull requests bevæger sig fra størrelse til første review-udfald og videre til merge, omarbejdning eller opgivelse. Erstat eksempeltallene med dine egne repository-data for at finde, hvor review går i stå.
Et Sankey-diagram over pull requests viser, hvad der sker med ændringer, efter de er åbnet: godkendt første gang, sendt tilbage til omarbejdning eller lukket. Grupperet efter størrelse viser det, om store ændringer er det, der bremser review.
Eksemplet har 250 pull requests: 120 små, 90 mellemstore og 40 store. Efter det første review er 130 godkendt, 90 har fået bedt om ændringer, og 30 er lukket uden review. Til sidst er 198 merget, 12 opgivet og 10 stadig åbne.
Bredderne gør prisen for størrelse synlig: 90 af de 120 små ændringer er godkendt første gang, men kun 5 af de 40 store. Omarbejdning er her én strøm, ikke en løkke, så en anmodning, der sendes tilbage to gange, tæller kun én gang efter sit endelige udfald. Se /da/sankey/ci-pipeline-outcomes for, hvad der sker med de builds, ændringerne udløser.
Sådan læser du dette diagram
- 198 af 250 pull requests (79 %) ender som merget; 12 % lukkes uden review.
- 75 % af de små ændringer (90 af 120) godkendes første gang, mod 13 % af de store (5 af 40).
- 70 af de 90 ændringer, der blev sendt tilbage (78 %), merges efter omarbejdning; 12 opgives.
- 10 anmodninger er stadig åbne, 8 af dem venter efter ønske om ændringer.
Data bag diagrammet
Opdigtede tal til illustration. Ikke data om nogen rigtig virksomhed, noget team eller system.
| Fra | Til | Mængde (pull requests) |
|---|---|---|
| Lille (under 100 linjer) | Godkendt første gang | 90 |
| Lille (under 100 linjer) | Ændringer ønsket | 22 |
| Lille (under 100 linjer) | Lukket uden review | 8 |
| Mellem | Godkendt første gang | 35 |
| Mellem | Ændringer ønsket | 45 |
| Mellem | Lukket uden review | 10 |
| Stor (over 500 linjer) | Godkendt første gang | 5 |
| Stor (over 500 linjer) | Ændringer ønsket | 23 |
| Stor (over 500 linjer) | Lukket uden review | 12 |
| Godkendt første gang | Merget | 128 |
| Godkendt første gang | Stadig åben | 2 |
| Ændringer ønsket | Merget | 70 |
| Ændringer ønsket | Opgivet | 12 |
| Ændringer ønsket | Stadig åben | 8 |
De samme data som CSV
source,target,value
Lille (under 100 linjer),Godkendt første gang,90
Lille (under 100 linjer),Ændringer ønsket,22
Lille (under 100 linjer),Lukket uden review,8
Mellem,Godkendt første gang,35
Mellem,Ændringer ønsket,45
Mellem,Lukket uden review,10
Stor (over 500 linjer),Godkendt første gang,5
Stor (over 500 linjer),Ændringer ønsket,23
Stor (over 500 linjer),Lukket uden review,12
Godkendt første gang,Merget,128
Godkendt første gang,Stadig åben,2
Ændringer ønsket,Merget,70
Ændringer ønsket,Opgivet,12
Ændringer ønsket,Stadig åben,8Sådan fungerer det
Eksportér pull requests for én periode
Medtag antal ændrede linjer, resultatet af det første review og den endelige tilstand. Tag ét kvartal eller én release.
Gruppér efter størrelse
Vælg to eller tre størrelsesbånd, og angiv, hvordan du skærer dem. Tæl hver anmodning én gang.
Tæl første review og endeligt udfald
Brug resultatet af det første review til den midterste kolonne og den endelige tilstand til den sidste.
Kontrollér balancen
Hver midterste node skal afgive lige så mange anmodninger, som den modtager. Lukket uden review ender der.
Ofte stillede spørgsmål
Hvorfor ikke tegne reviewrunder som en løkke?
Fordi bredderne viser antal, og en løkke får den samme anmodning til at tælle to gange. Hvis runderne har betydning, så lav et andet diagram med antal runder som midterkolonne.
Vises reviewhastigheden?
Nej. Bredderne er antal. Sæt tid til første review i en tabel ved siden af diagrammet eller i et separat diagram over tidsbåndene.
Redigér dette Sankey-diagram over pull requests
Åbn eksemplet som dit eget diagram, og indtast dit repositorys antal.