Build Log

Counts code delivered to the tracked repos only. Project management, client and sales work, meetings, support, deployments and design are not measured here. What is and is not counted ↓

People

Team points per day

How ratings and points are calculated ↓

Quality and workload

Click a person for their full profile. Bugs are traced with git blame and then checked in the code: every change to 3+ lines someone wrote in the previous days is reviewed from the before and after code, not the commit message, and marked as a bug fix (the old code was wrong), rework (unfinished work redone or completed) or a normal change. Fixes to older code are attributed to its git author separately. Line rates are per 1,000 lines each person wrote (recent work: in the period; older code: over all time), so heavy and light committers compare fairly. Big mixed commits only count as fixes when the review classed them as a fix. Work from the last 14 days is still settling, so its bug count can still rise.

Who works where

Points per area in the selected period. A row with one strong cell means only one person knows that area well.

Work feed

How scoring works

This page shows what was built across our repos and how big or hard each piece of work was. Here is exactly how the numbers are produced.

1. CollectCommits from every tracked branch are pulled in on each sync. Syncs only add: nothing that was already recorded is removed or replaced.

2. Split into topicsEach person's commits for the day are split into separate pieces of work: one feature, fix or refactor each. Ten small commits for one job score as one job, and three unrelated jobs on one day score as three.

3. RateEach piece of work gets a level from L1 to L5 after reading its actual code changes, not just the commit message (see below).

4. ScoreThe level converts to points. A person's total is the sum of points from their work in the selected period.

Levels and points

Points rise faster than levels on purpose. One L5 job (10 pt) is worth more than five L1 fixes (5 pt), because hard, risky work takes far more thought than its line count suggests. Test pushes and changes that were reverted are shown as L0 · no credit.

What decides the level

Scope: how many files and modules the change touches, and whether it is a new feature, a fix or a tweak.
Risk: changes to login, security, permissions, payments, database structure or data correctness rate higher. These show as warning chips (security, db, payment) on each item.
What the code really does: The automated review reads the actual code changes and writes a one-line reason for every rating. A five-line SQL injection fix can be L5, and a 2,000-line copy-paste can be L2.
Tests: adding tests alongside the change counts in its favour.
Same standard for everyone: every rating follows one written rubric with fixed reference examples, and names play no part, the lead's work included.

Fairness rules

The same patch pushed to more than one branch (for example master, phplatest and development) counts once.
Line counts leave out vendor libraries, machine-translated language files, generated Flutter localisation, lock files and images. en.php still counts.
Reverts and "test" commits that get undone add nothing to the rating.
One big commit that bundles weeks of work (a squash) has its points spread back over the days since that person's previous commit, so the chart shows when the work happened. It is marked "spread over N days".
Only shared branches are tracked. Work still on your own machine or a private branch appears once it is pushed or merged.
A lead can adjust any rating. Adjusted items are marked "adjusted by lead".

Quality: how each figure is calculated

Quality figures are calculated from git history. Every figure links to the actual pieces of work on each person's profile, so anyone can check it.

Figure	How it is calculated
Bugs found in their work	Git blame finds every later change to 3+ lines a person wrote in the previous 30 days. Each one is reviewed from the before and after code, not the commit message, and counts as a bug only when the old code was wrong (a crash, wrong result, missing check, broken behaviour). The reason is shown on the profile. Same person, same day is treated as work in progress and not counted.
By others / self	Who made the fix. A bug someone else had to fix weighs more than one a person caught themselves.
Per 1k lines	Lines of their code fixed, divided by the hand-written lines they added in the period, times 1,000. This makes heavy and light committers comparable.
Pieces with a later fix	Share of their pieces of work at least 14 days old (settled) that needed any bug fix later. Bigger pieces are more likely to need one, so read it next to the per-1k figures.
Rework	Lines of recent work that were later redone or completed for the same goal: a first attempt replaced, half-built logic finished. Judged from the code, per 1k lines written. High rework points to work shipped before it was finished.
Repairs to others' code	Bug fixes they made to code written by colleagues, recent or older. Shows who catches and repairs problems for the team.
Older code fixed by others	Fixes by colleagues to a person's code older than 30 days, divided by all lines that person has ever added, per 1k. Long-serving authors are not penalised for simply having written more of the system.
Reverted	Their pieces of work that were later undone with a revert, and by whom.
Short-lived code	Share of their new lines replaced by anyone within 21 days, for any reason.
Tests	Share of their pieces of work that add or change automated tests.
Review flags	An automatic scan of added lines. High: hardcoded passwords or keys, SQL built from request input, unescaped request output, eval. Medium: TLS certificate checks turned off, API keys in browser code. Style notes: SQL strings built with variables, leftover debug output. Secret values are masked.

Workload: how each figure is calculated

Figure	How it is calculated
Active days	Days with at least one commit in the period, and how many were weekends.
Points per active day	Period points divided by active days.
Topics per day	Pieces of work per active day. Many topics a day means a lot of context switching.
After hours	Share of commits made before 8am or after 7pm, in the committer's own time zone.
Longest quiet stretch	Most weekdays in a row with no commit between two active days. Can mean leave, other duties or blocked work.
Giant commits	Commits over 3,000 changed lines, which are hard for anyone to review.
Vague messages	Share of commit messages like "fix", "changes", "retest" or under 10 characters. A working habit shown for information; it does not affect points or quality figures.
Output vs team	Points, active days and points per active day compared with the team median for the selected period. Under 60% of the median shows a catch-up target: the median's weekly points, also given as medium (L3, 4 pt) pieces.
Who works where	Each piece's points split across its 1–2 areas, summed per person.

The written assessment on each profile is generated by the automated review from these figures and the linked evidence, and refreshed on each sync. It is a starting point for a conversation, not a verdict.

What the points do not measure

Only code pushed to the tracked repos is counted. None of this appears here, however valuable:

Project and client work: project management, client meetings and site visits, requirement gathering, demos, training and user acceptance testing.
Business work: sales support, presales, proposals and tenders, marketing material, product planning.
Team work: meetings, planning, code reviews, helping or mentoring colleagues, interviews, documentation outside the repos.
Operations: customer support and troubleshooting, server and DNS setup, deployments, database fixes run by hand, data migration, backups, monitoring.
Design and research: UI/UX design, mockups, prototypes not pushed, research and learning.
Time itself: hours worked, leave, overtime spent on calls, and work done in other repositories or branches that are not tracked.

Quality is shown beside the points, not deducted from them. A big change that later needs fixes keeps its points; the bug and rework figures show the follow-up.

Use it to see what is being built and where the heavy work is, not as a ranking on its own.

Scored on what you deliver

Levels, bugs and rework are judged from the code itself. Commit messages are only a hint and never raise or lower a score.
A commit that mixes several jobs is rated on everything in it, so nobody loses credit for how they commit.
Many small commits for one job score the same as one commit: the work is grouped by topic first.
"Vague messages" and "giant commits" are shown as working habits only. They do not change points.
Work is counted once it reaches a shared branch, so push regularly.
If a rating looks wrong, tell your lead which item and why. It can be adjusted and is marked "adjusted by lead".

Clear messages such as Booking: stop recurring bookings reusing one ID still help the team read the history.