Ship Weight
Complexity-weighted throughput, shown next to Merged PRs.
What it means
Merged PRs counts every merge the same. Ship Weight answers a different question: how much review load those merges represent.
Each merged GitHub pull request gets an integer score from 0 to 10. A week with 20 tiny docs PRs can look busy on Merged PRs and quiet on Ship Weight. A week with 4 dense code PRs can look the opposite.
| Per-PR score | What it usually means |
|---|---|
| 0 | Change doesn’t contribute to ship weight (docs, config, assets, or a revert). In Productivity Insights the day drawer shows 0; hover for that explanation. |
| 1 to 3 | Small or lightly weighted change: few kept files, mostly tests/config/docs, or lots of deletions. |
| 4 to 7 | Typical feature or bugfix with real production code. |
| 8 to 10 | Large, dense, code-heavy diff. 10 is the cap; bigger PRs do not go higher. |
Charts, tables, and heatmaps sum those per-PR scores for the day or week you are viewing. On team and portfolio views, Avg ship weight (weekly) (or per day) is the mean of each bucket’s total divided by engineers with at least one merged PR in that bucket. Trend charts still show raw bucket totals. On a single contributor’s page, Avg is that person’s own mean across buckets.
Ship Weight does not replace Merged PRs. Both stay available. It is also not raw line count (use PR size in SDLC Insights for lines).
How it’s calculated
After a pull request merges, the platform reads that PR’s file list from GitHub (path, add/modify/remove, and line changes). Same files always produce the same score.
1. Classify each file
Path rules run first (test folders, generated paths, and similar), then the file extension. Each file gets a type and a density (how information-dense that kind of file is). New files use a “new” density; everything else uses a “modified” density. A production-code path under test/ / tests/ / spec/ is treated as a test.
2. Weight the change
For each file we combine:
- How much changed on that file (GitHub’s line-change count)
- Density for that type of file
- File type (code counts more than tests; docs and assets count little or not at all)
- Change type (edits count more than adds; deletes and empty renames count little or nothing)
Tiny leftovers below a trivial threshold are dropped.
| File kind | How it counts |
|---|---|
| Production code | Full weight |
| Tests | Less than production code |
| Styles, templates, config | Discounted |
| Docs | Small |
| Assets, generated files, translations, most data files | Usually ignored |
| Config-heavy PRs (about 75% or more of meaningful files are config or data) | Config (and non-tabular data) is raised so infra/config work is not invisible |
| Change | How it counts |
|---|---|
| Modified | Full weight |
| Added | Slightly less than a modify |
| Removed | Low |
| Renamed with no other edits | Ignored |
3. Scale to 0 to 10
If no files are kept after weighting, the score is 0. Otherwise kept files are added up, nudged slightly upward when many files are involved, then scaled onto 1 to 10 and rounded. The result is never above 10.
Special cases
- Score 0: The change doesn’t contribute to ship weight (docs, config, assets, or a revert). Also empty diffs and similar ignored-only changes.
- Stacked / “slush” parents: When a parent PR has children already merged into its head branch, the parent only keeps the residual weight that those children did not already ship. That avoids double-counting stacked work. Residual can also be 0.
- Unscored yet: Merges still waiting on ingest show Backfilling in the UI, not a numeric 0. Score 0 means scoring finished and nothing weighted remained.
The in-app info tooltip labels this model v13. The weights above are the customer-facing summary; they are not a line-by-line formula.
Where it shows up
Productivity Insights
Open Insights → Productivity Insights. On Overview, By User, By Team, and contributor or team drilldowns, use the Merged PRs / Ship Weight tabs. The same toggle drives KPIs, trend charts, contributor and team tables, leaders/laggards, heatmaps, and the day drawer (including the per-PR list).
Default is Merged PRs. Your choice is remembered in this browser.
Your AI Journey
Open AI Journey in the sidebar (/dashboard):
- Hero Ship weight next to PRs merged (last 7 days, with week-over-week delta when scoring is complete)
- PR velocity & failure signal: tabs for Merged PRs, Ship Weight, and CI Failures (CI only when GitHub Actions is enabled for the workspace)
- The embedded Productivity card uses the same Merged PRs / Ship Weight toggle
Backfilling
New or historical merges can show Backfilling until scoring finishes. Merged PR counts still work in that window. Switch back to Merged PRs if you need volume right now, or wait for ingest to catch up.
Ship Weight needs a connected GitHub App. No extra permission beyond what Insights already uses for pull requests. Historical merges still waiting on scoring show Backfilling until ingest catches up. That is not the same as a scored 0 result.
Weekly targets
Workspace admins can set an optional weekly per-engineer Ship Weight floor under {workspace} settings → Productivity Insights, next to Merged PRs and CI Failures. See Productivity Insights.