Summary
Introducing a simple risk score for pull requests to help prioritize human review and use CI resources more effectively.
Why this is useful
- Ensures higher‑risk changes get timely attention, reducing regressions.
- Reduces reviewer overload by making priorities clearer.
- Saves CI time and effort by avoiding heavy checks for low‑risk changes.
Signals (examples)
- S1 — Path mapping: infer area (platform, workbench, editor) and detect changes to sensitive entrypoints (e.g.
electron-main).
- S2 — Surface of change: diff size, number of files, presence of
*.d.ts or entrypoint modifications.
- S3 — Churn history: recent commit density or fixes on touched files.
- S4 — Test evidence: presence/updates of tests or referenced test plans.
Summary
Introducing a simple risk score for pull requests to help prioritize human review and use CI resources more effectively.
Why this is useful
Signals (examples)
electron-main).*.d.tsor entrypoint modifications.