This page describes how to gain access to filter on a committer's historical Diff Delta 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:
linkWhat limitations are there on filtering individual committers' data?
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.
We believe that managers don't want to babysit their developers, and are thus best-served by configuring their own Diff Delta-as-incentive system (e.g., delete more code, reduce support tickets), so they can point to it and say "optimize for these things."
Allowing developers to control how/where their data is available lets them 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 to managers: proof that your team is committed to a dev-first culture. When other Developer Analytics tools exclude developers from having a place in the measurement process, that ruse only works until the Managers has to explain to a Developer what data they are using to judge the team's coding effort. When the dev learns that a noisy or fail-prone metric is the primary source of truth, team culture invariably suffers.
linkAutomatically receive report access on new developer signup
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.
linkRequest report access from all current & future developers
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.
linkIncommunicado developers
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.
linkRequest report access from an individual contributor
Individual committers can request and grant access to filter on their individual data.
linkVia Settings -> Contributors
The easiest location to request access is the "Contributors" list within GitClear settings:
How to request report access via Contributors list
If you have a large team, you can use the filter at the top of the page to find the specific committer you want to request access from.
linkVia Settings -> Teams
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.
linkResponding to a committer access request
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.