PR Size Metric

Definition

The PR Size Metric measures the total number of lines of code added, modified, or deleted in a pull request (PR) after excluding files specified in the organization's settings or repository settings.

Why is This Metric Useful?

• Larger PRs can be more challenging to review, leading to longer review times and increased potential for missed issues. By monitoring PR sizes, teams can encourage smaller, more manageable PRs that improve review efficiency and depth.

How to Use it?

• Promote smaller, more focused PRs to streamline reviews and improve code quality.
• Adjust repository settings to exclude non-relevant file types, such as documentation or auto-generated files, from size calculations.

Examples for Context

• Teams that limited PR sizes to 500 lines observed improved review depth and faster merge times.
• Excluding specific file types reduced unnecessary review overhead and focused reviewer efforts on critical code changes.

Data Sources

• Repository diff data, excluding files filtered in the settings (e.g., files with specific extensions or paths).

Calculation

• PR Size = Sum of lines added, modified, and deleted in the PR - Changes in excluded files.

Tunable Configurations

Exclusion Filters: Configure specific file types or paths to be ignored in PR size calculations. Files matching these patterns will be excluded from analysis, ensuring that non-relevant changes, such as documentation updates, auto-generated files, or configuration modifications, do not impact PR size metrics.

Examples of exclusion filters:

• Dependency and configuration files, such as package-lock.json.
• Build and distribution artifacts, such as files in dist/ or public/assets/.
• Non-code files, including .csv, .docx, .txt, .log, and .tar.

Exclusion rules are applied before inclusion rules, meaning any files filtered out at this stage will not be considered, even if they match inclusion criteria.

Inclusion Filters: Configure specific file types or paths to be included in PR size calculations. When inclusion filters are set, only the specified files will be considered, and all others will be ignored. This allows teams to focus on relevant code changes while excluding unrelated modifications.

Examples of inclusion filters:

• Limiting analysis to source code files while ignoring documentation or configuration files.
• Tracking changes only in specific critical files, such as requirements.txt or package.json.

Benchmarking Guidance

• PR sizes should generally remain below 500 lines for optimal review efficiency.

Error Margins and Limitations

• Non-code files or excluded changes may still affect the comprehensiveness of review metrics
• Auto-generated or large binary files not properly excluded could inflate size calculations.

Stakeholder Use Cases

• Developers: Create smaller PRs to improve review efficiency and reduce feedback cycles.
• Reviewers: Focus efforts on meaningful changes by avoiding noise from excluded file types.