Definitions

Churn

Churn is when a developer re-writes their own code shortly after it has been checked in - less than 3 weeks old. A certain amount of Churn should be expected from every developer.

Commits

It represents the amount of commits done by the developer

Comments addressed

It represents the percentage of Reviewer comments that were responded to with a comment or a code revision.

Coding

Time to Issue PR from First Commit. This metric corresponds to the coding time, and is the time elapsed from the first commit to creating a PR.

Change Failure Rate

The percentage of builds or deployments that are cancelled or result in failures.

Cycle Time

Cycle Time is an indicator of an organization's development velocity. The Cycle Time metric is the sum of four metrics, each of these metrics corresponding to a stage in the software development process: | Coding | Pickup | Review | Deploy |

Deploy

Time to Deploy from Merge. This metric is an indicator for how fast does code get deployed into production, and is the time between when a PR is merged to when it gets released into production.

Deployment Frequency

How often you deploy code to production.

DORA Metrics

Efficiency

It is the percentage of an engineer’s contributed code that’s productive, which generally involves balancing coding output against the code’s longevity. Efficiency is independent of the amount of code written.The higher the efficiency rate, the longer that code is providing business value. A high churn rate reduces it.

Follow-on Commits

Follow-on Commits is the number of code revisions once a Pull Request is opened for review.

Help Others

It describes how much an engineer is replacing another engineer's recent code - less than 3 weeks old.

Impact

Impact is a way to measure the amplitude of code changes that are happening in a more complex manner rather than measuring raw lines of code. Impact is a measure of work size that takes this into account. Impact takes the following into account: | What percentage of the work is edited to old code. | The surface area of the change (think 'number of edit locations'). | The number of files affected. | The severity of changes when old code is modified. | How this change compares to others from the project history.

Involvement

Involvement is the percentage of PRs a reviewer participated in. It’s important to note that this metric is a highly context-based metric. At an individual or team level, “higher” is not necessarily better as it can point to a behavior where people are overly-involved in the review process, but there are certain situations where you’d expect to see Involvement very high, sometimes from a particular person on the team and other times from a group that’s working on a specific project

Influence

Influence is the ratio of follow-on commits to comments made in PRs.

Legacy Refactor

Legacy Refactor is the process of paying down on “technical debt”. The process of improving the structure of an old or unfamiliar code without changing its functionality

Lead Time for Changes

The time it takes for commited code to code successfully running in production.

Merged Without Rebase

Merged Without Rebase is the total number of Pull Requests merged without a rebase.

Merged Without Review

Merged Without Review is the total number of Pull Requests merged without a review.

Merged

Merged is the total number of Merged Pull Requests.

Mean Time to Recovery

How much time does it take to issue a successful deployment on the same repository and branch, after a failed or cancelled deployment occurs.

Maker Time

Maker Time is the total amount of free time in which an engineer can focus, calculated at 2-hour intervals without interruption.

New Code

Brand new code that does not replace other code.

No. of Reviews Left

No. of Reviews Left is the total number of reviews across all Pull Requests.

No. of Comments Left

No. of Comments Left is the total number of comments across all Pull Requests.

No. of Reviews

No. of Reviews is the total number of reviews in all Pull Requests.

No. of Comments

No. of Comments is the total number of comments in all Pull Requests.

Open

Open is the total number of Open Pull Requests.

Productive Throughput

It represents the proportion of code without churn.

PRs

It represents the number of pull requests created by an engineer.

PRs Open

It represents the number of open pull requests of an engineer.

PRs Closed

It represents the number of closed pull requests of an engineer.

PRs Merged

It represents the number of merged pull requests of an engineer.

PRs merged without review

It represents the number of pull requests merged without review by an engineer.

PR Comments Adressed

It represents the number of comments addressed by an engineer in all pull requests.

PR Reviews Addressed

It represents the number of reviews addressed by an engineer in all pull requests.

Pickup

Time to First Review. This metric indicates how fast do reviewers pick up their peers' PRs for review, and is the time between when a PR is opened and the first time an engineer reviews that PR.

Pull Request Risk

It represents a measure of how likely it is for a particular commit to cause problems. Think of this as a pattern-matching engine, where Waydev is looking for anomalies that might cause problems. Some of the data points for the Pull Request Risk include: | The number of commits | The size of the commits | The spread of the changes | The depth of the changes |

Risk

Risk is a measure of how likely it is a particular commit will cause problems. Think of this as a pattern-matching engine, where Waydev is looking for anomalies that might cause problems. Some questions that we ask are: | How big is the commit? | Are the changes tightly grouped or spread throughout the code base? | How serious are the edits being made - are they trivial edits or deeper, more severe changes to existing code?

Responsiveness

It represents the average time it takes to respond to a comment with either another comment or a code revision.

Receptiveness

It represents the ratio of follow-on commits to comments. It’s important to remember that Receptiveness is a ‘goldilocks’ metric—you’d never expect this metric to go up to 100%, and if you did it’d be indicative of a fairly unhealthy dynamic where every single comment lead to a change.

Reviewer Metrics

Reviewer Metrics provide a gauge for whether reviewers are providing thoughtful, timely feedback. Reviewer Metrics are: | Reaction Time | Involvement | Inluence | Review Coverage

Reaction Time

Reaction time is the average time it took to respond to a comment.

Review coverage

Review coverage represents the percentage of PRs reviewed.

Robust Comments

Robust comments are comments that have a length over 200 characters.

Regular Comments

Regular comments are comments that span between 100-200 characters

Reviewers

Reviewers is the number of reviewers per Pull Request.

Reviewer Comments

Reviewer Comments is the number of reviewer comments per Pull Request.

Review

Time to Merge from First Review. This metric signifies how fast do submitters incorporate feedback from their peers in code review, and is the time from a PR's first review to that PR being merged.

Submitter Metrics

It quantifies how submitters are responding to comments, engaging in discussion, and incorporating suggestions. Some submitter metrics are: | Responsiveness | Comments Addressed | Receptiveness | Unreviewed PRs

Sharing Index Metrics

Sharing Index metrics are: | PRs is the total number of PRs that were reviewed. | Sharing Index measures how broadly information is being shared amongst a team by looking at who is reviewing whose PRs. | Active Reviewers is the count of active users who actually reviewed a PR in the selected time period. | Submitters is the total number of users who submitted a PR in the selected time period.

Sharing Index

Sharing Index measures how broadly information is being shared amongst a team by looking at who is reviewing whose PRs.

Submitters

Submitters is the total number of users who submitted a PR in the selected time period.

Throughput

It represents the total amount of code of new, churn, help others and refactored code.

Technical Debt

It is the amount of refactoring code done by the developer

tt100

It is the time it takes for an engineer to create 100 productive lines of code ( code without churn)

Trivial Comments

Trivial comments are comments that have under 100 characters.

Time to Resolve

Time to Resolve is the time it takes to close a Pull Request.

Time to First Comment

Time to First Comment is the time between when a Pull Request is opened and the time the first engineer comments.

Total

Total is the total number of Pull Requests.

Unreviewed PRs

It represents the percentage of PRs submitted that had no comments.

Work Type

It represents the highest types of work an engineer is focused on (New Work, Legacy Refactor, Help Others, and Churn).

Without Comments

Without Comments is the total number of Pull Requests that have no comments.

Without Reviews

Without Reviews is the total number of Pull Requests that have no reviews.