Developer Analytics tools like GitClear face a fundamental problem. Their subscriptions are purchased by CTOs, VPs of Engineering and CEOs, which means that these tools face constant pressure to provide any comparative report that is requested by the subscription-deciding leaders at a company.
GitClear is one among many Developer Analytics tools that claims to be "developer-friendly." But there is a deep tension between "creating the comparative reports requested by managers" and "being developer-friendly." The instant a developer has to worry that a metric or tool can be used to compare them unfavorably, the hope to win that developer's trust is lost.
Because of the intrinsic tension between "what managers will ask for" and "what serves a developers interests," we believe it's incumbent upon Developer Analytics tools to be transparent about what data is shown to which users. When a developer hears about a tool that can quantify commit activity, the reflexive instinct for many is to imagine how the measurement will be misinterpreted or misused by bad managers. This policy document will outline specifically how GitClear has designed its report access to keep power in the hands of developers.
linkPolicy 1: Historical stats aggregated by team, not committer
The first step to preventing metric misuse is our policy that historic data available to managers must be grouped by team, rather than individual.
Following a list of the non-aggregated reports on GitClear that identify individual contributors. Each report includes a screenshot of the report for transparency, plus our reason for offering the report.
Commit Activity Browser. This page doesn't aggregate data or stats. It provides a short-term glimpse at the last few days so that the managers can keep in the loop about what projects are currently underway without having to disrupt their developers' flow state.
Directory Browser and its sibling report Tech Debt Inspector. The three most active committers in a given directory or file are shown while browsing the repo. This allows developers that are new to the repo to get a sense for who they might direct their questions toward if they are going to be making contributions in a new directory.
Pull Request Stats. There are two graphs in the pull requests section that allow developer comparison: the "PR comments left" chart and "PR comments received" chart. These reports allow the team to get a high-level look at the collaborative practices of their team. This data does not relate to a developer's productivity, so it is visible.
Domain Experts Report. This report will list up to three developers that have made the greatest number of contributions to each code category during the selected time period. This data allows managers to get a sense for which developers might be good candidates to tackle Jira tickets that will require work in a certain language or library. It can not be used comparatively since any project will have tens of code categories, offering every developer the opportunity to shine in their niche.
Individual developers can choose whether to share their data with collaborators they trust.
See also: How to request & grant access to individual committer data for shared collaborators
linkPolicy 2: Developer-only reports promote self-directed improvement
The most common GitClear use case is that of an individual contributor that wants to experiment with different tactics to get more done in a day. For these self-driven developers, GitClear offers the option to filter any report on themselves from the team selector:
Filtering on a committer's own activity
As suggested by the iconography, a committer's personal stats are just that -- personal. Managers and executives can not see these filtered reports, only the developer themselves can. There are several reports of interest for a self-focused developer, including the Hourly Impact report, the Diff Delta History report, and the "Biggest Tickets worked on" report. There is also the Cohort Report, available exclusively to developers,
linkPolicy 3: Document the limitations of Diff Delta (not a productivity metric)
Diff Delta is a metric that measures the rate of repo evolution, optionally with an emphasis on deleting code, writing tests, or removing code in legacy directories. When developers think about their greatest streaks of "productivity," there is often rapid code change entailed, but not always. And from a manager's perspective, "developer productivity" usually means that the code changes taking place are in service of the product roadmap. Diff Delta doesn't change based on these factors, which is why we have been clear since our inception that Diff Delta is not a metric that measures developer productivity.
link"Do no harm" enforcement
If you are a developer that believes that a GitClear report has been misused by a manager as a comparison tool, please email bill@gitclear.com with the circumstances of your situation. We pledge to respond within two business days, and to continue to evolve our policies and reports in the event we receive reports from developers who believe that GitClear's data has been used to the detriment of themselves or their team.