Platform
Individual and team performance, with the evidence attached.
Most engineering analytics stops at the team boundary and leaves managers to run reviews on memory. Pacia reports at both levels — a ranked contributor board, a per-person insight view, team comparison and benchmarks — and every figure on all four opens to the pull requests it was computed from.
- 1 · A. Okafor
- 34 merged · 22% of team
- 2 · M. Lindqvist
- 29 merged · 19% of team
- 3 · P. Raman
- 24 merged · 16% of team
- 4 · J. Whitcombe
- 21 merged · 14% of team
- Metric selector
- 7 metrics, any date range
Any row opens to that person’s pull requests for the period.
Four views, two altitudes
Leaderboard
A ranked contributor table over any date range, filtered by team, repository or named individual. Pick the metric that matches the question, and set a threshold to isolate everyone above or below a line.
Seven metrics
Total PRs, merged PRs, merge rate, total additions, files changed, test ratio and repository count. Every column ranks on the underlying number rather than the rendered label.
Share of team
Each contributor’s percentage of their team’s total on the selected metric. This is the number that exposes a review queue resting on two people, and the one worth acting on fastest.
Contributor insights
The same underlying data as an individual lookup rather than a ranking — one person, their trend, their repositories. The view to open before a one-to-one, and the one each person can open about themselves.
Standout cards
Most PRs merged, most involved, most lines shipped and best test coverage over the period you chose. Recognition is easier to give fairly when it does not depend on who was most visible in stand-up.
Team insights & benchmarks
The same rigour one level up — team against team on identical definitions, and against the standard DORA performance bands.
From a rank to the work behind it
Position and trend identify the question. The selected period, underlying value and exact pull requests provide the evidence needed to answer it in context.
A contributor number is the start of the conversation
- 1Select the questionMetric, team and date range
- 2See position + trendUnderlying value and share of team
- 3Open the evidenceThe exact pull requests behind the figure
- 4Add contextReview load, flow and the work itself
No rank is presented as a verdict. The person and the manager can open the same evidence, over the same period, before using it in a review.
What makes these numbers usable in a review
The failure mode for contributor metrics is well documented, and essentially all of it comes from figures nobody could interrogate. These are the things that prevent that.
Every figure drills to the work
A rank, a count and a percentage all open to the specific pull requests behind them. A number that can be opened gets discussed; a number that cannot gets argued about, and that argument cannot be settled in either direction.
Trend beside position
Each row carries a sparkline over the selected range. Fourth and climbing steeply is a different conversation from fourth and falling, and a static table cannot tell them apart.
The person sees what the manager sees
Contributor Insights gives each engineer their own figures and trend from the same data. Nobody should meet their numbers for the first time in a review — and a metric people can check for themselves is one they argue with productively rather than resent.
Scoped to what the viewer may see
Members are restricted to their own teams’ data, enforced in the query services rather than hidden in the interface. Owners and admins see the whole organisation.
Your date range, not a fixed month
Every board is computed over the window you choose. A review covering six months should be measured over six months, not over whatever period the tool happened to default to.
Common questions
Does Pacia rank individual contributors?
Yes. The Leaderboard is a ranked contributor table with a position column, seven selectable metrics, share-of-team percentages and trend sparklines, over any date range. Contributor Insights presents the same data as a single-person lookup for when a ranking is not what you need.
Who can see the performance boards?
Any signed-in user, scoped to what they are entitled to: members see their own teams, owners and admins see the whole organisation. That restriction is applied in the queries, not only in the interface.
Which metrics can we rank on?
Total pull requests, merged pull requests, merge rate, total additions, files changed, test ratio and repository count — plus each contributor’s share of their team’s total. You can also filter to everyone above or below a threshold on the selected metric.
Can we use this in performance reviews?
That is what the drill-down exists for. Open the period, open the metric, open the pull requests behind the figure, and the conversation runs on the actual work rather than on recollection. Read it alongside cycle time and review load so contribution is understood in context rather than as raw volume.
Does this need Jira?
No. Every board here is computed from pull request data across GitHub, GitLab, Azure DevOps and Bitbucket.