GitHub · Available
Every merge, review and deploy, credited to a person.
Install the app on the repositories you choose and the board fills with the previous 90 days before the first live event arrives. Nobody signs in to an empty leaderboard.
- Status
- Available
- Authenticated with
- A webhook secret issued per installation, verified on every delivery.
- Becomes
- merged · approvals · deploys
What it sends
What arrives, and what it becomes on a board
| When | Becomes | Worth knowing |
|---|---|---|
| A pull request is merged | merged | Closed without merging counts for nothing. The event carries the hours from open to merge, so time-to-merge is available as a real percentile, and the diff size, which is kept as context rather than scored. |
| A review is approved | approvals | Only approvals. Comments and change requests are participation, not the thing the board measures; counting them would make "reviewer" mean "commenter". It also carries the hours the pull request waited on that reviewer, as its own percentile. |
| A deployment succeeds | deploys | From the deployment status, with the environment kept on the event, so a rule can pay more for production than for staging. |
Three events, because these are the three GitHub can attest to. Anything else your team does, such as an incident handled or a release cut, arrives through the signed webhook and ranks beside them.
Setting it up
Three steps, and none of them is a ticket to us.
- 01
Install the app
From the Integrations page inside the product. Pick every repository or a few; you can change it later in GitHub.
- 02
Wait about a minute
The install loads the previous 90 days, so the Contributors, Reviewers and Shipping boards have something on them before anyone looks.
- 03
Link identities once
A GitHub login that matches a member’s email is linked for you. The rest appear on the identities page for a one-time match, and their history follows.
What it will not do
The refusals, in writing.
- Read your code. The app receives events about pull requests and deployments, not their contents.
- Rank bots. Anything GitHub marks [bot], plus dependabot, renovate, github-actions and the usual suspects, is ignored by default, and you can add your own.
- Count the same merge twice. Redeliveries, a second install, and running the backfill again all land on the same record.
- Write anything back. No comments, no statuses, no commits. Notifications go to Slack or email, never into your repository.
Questions
The ones that come up
Does it need admin on the organization?
No. Installing a GitHub App needs permission on the repositories you select, which a repository admin has. It does not ask for organization-level administration.
What about work in a private repository?
The same as a public one. The app only receives events for the repositories it is installed on, and it never reads file contents from any of them.
Somebody has two GitHub accounts.
Link both to the same person on the identities page and the work they already did is re-attributed. Nothing is counted twice; it is the same events under one name.
Can I turn off deploys, or reviews, from the board?
Yes. A board ranks the metrics you choose, so a Reviewers board simply does not include merges. The events are still recorded, so you can add them back later.