This page describes how to gain access to filter on a committer's historical Line Impact stats. It is a companion to GitClear's Policy on Dev-Friendly Metrics, which describes why we believe both managers and developers are, with a few exceptions, best served by focusing their improvement efforts at the team level, as opposed to the individual level.
When does it make sense to focus on individual-level reports instead of team-level reports?
The most common case is when one wants to view one's own stats. Filtering on personal stats allows a developer to privately gauge how their velocity is progressing relative to their expectations. The second most common case is Lead Developers or CTOs that want to help onboard a new developer. When you're trying to help a new committer get up-to-speed in a repo, sometimes it makes sense to look through their stats at an individual level.
Topics covered in this help page:
The long version can be found within our Policy on Creating the Most Developer Friendly Metrics. The short version is that for developers to use & benefit from GitClear, they must start by trusting it.
Even though managers that misuse data are hard to find in the wild, almost every developer harbors a deep-seated fear that their git data might someday be used against them by a bad manager. On the other hand, most managers simply want their developers to be receptive to using measurement for self-improvement.
In the long-term, we think that many managers don't want to babysit devs, and will be best-served by configuring their own Line Impact as an incentive system (e.g., delete more code, reduce support tickets), then point their devs to it and say "optimize for that when we're in 'product build' mode."
Allowing developers to control who can view their individual data enables them to feel safe using GitClear. Contrast this to a manager that forces developers to maximize for a metric like "code churn" that muddles together 5+ different factors. When management's report use is equally transparent as a developer's activity pattern, everybody can use that information to work toward measurable progress.
There's also a secondary benefit: proof that your team is committed to a dev-first culture. While other Developer Analytics tools exclude developers from having a place in the measurement process, GitClear puts developers at the center of their improvement. For developers that care about transparency and fairness, choosing GitClear is a testament that manager wants to work with their developers, instead of against or around them.
By default, when you invite a user to GitClear, they will be encouraged to allow their invited user to enable stat filtering:
When signing up, a user will be asked to confirm they want to share individual report access with their inviting manager
Unless the user unchecks this box, the inviting user will receive the ability to filter on individual committer reports after the developer has signed in.
The checkbox to request individual data access from all committers is at the bottom of the team form
If you would like to be able to view individual committer data for every developer in a team, you can use the "Automatically request committer report access" checkbox at the bottom of the team form. This will notify all committers with an email address on file that you would like to enable access to view their reports. As of Q2 2022, the email looks like this:
Email asking committer to approve individual report access
The committer does not need to sign up for GitClear or be granted an account. As long as the git provider (or you) supply the committer's email address, all GitClear needs is the "Approve request" button to be clicked, and that committer's report data will be visible to the manager who requested it.
When you have the "Automatically request committer report access" box checked for a team, any newly active developer who joins the team will automatically have an access request sent to them.
If a developer's email address is not known by the git provider, or if the developer does not respond to their access request notification, committer report access request will be granted 7 days after the initial request.
Individual committers can request and grant access to filter on their individual data. Access is requested from the Settings -> Teams & Users page, where the "Choose an action" dropdown will allow "request report access" for users associated with committers:
Requesting access to filter on an individual committer's stats
After requesting access, the icon at the left edge of the row will change to yellow to indicate that access has been requested.
When a committer access request is sent, you'll receive an email with a button that can approve an access request without requiring GitClear login. However, if you don't respond to that email, you can also review and approve access requests from the Settings -> Account -> Committer report access:
Respond to an undecided committer access request
If you deny the request, the requester's status will be left as "Pending approval," so there is no apparent different from a requester's standpoint between a request that is pending vs. declined. We leave it as an exercise to the developer to communicate to the requester the rationale behind their decision.
The button to "Allow" access will continue to be available even after clicking to "Deny" a request, so it's easy to change your mind.