Definitions

Hover for definitions

A

Active DaysActive Days - They represent any day where an engineer contributed code to the project.

They represent any day where an engineer contributed code to the project.

Active ReviewersActive Reviewers - Active Reviewers is the count of active users who actually reviewed a PR in the selected time period.

Active Reviewers is the count of active users who actually reviewed a PR in the selected time period.

Avg. Comments per ReviewerAvg. Comments per Reviewer - Avg. Comments per Reviewer is the average number of comments per Reviewer.

Avg. Comments per Reviewer is the average number of comments per Reviewer.

Avg. Time to First CommentAvg. Time to First Comment - Avg. Time to First Comment is the average time between when a Pull Request is opened and the first time an engineer comments.

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

Avg. Time to First ReviewAvg. Time to First Review - Avg. Time to First Review is the average time between when a Pull Request is opened and the first time an engineer reviews the pull request.

Avg. Time to First Review is the average time between when a Pull Request is opened and the first time an engineer reviews the pull request.

Avg. Time Merge from CreateAvg. Time Merge from Create - Avg. Time Merge from Create is the average time from a Pull Request creation to it being merged.

Avg. Time Merge from Create is the average time from a Pull Request creation to it being merged.

Avg. Time Merge from First CommitAvg. Time Merge from First Commit - Avg. Time Merge from First Commit is the average time from a Pull Request first commit to it being merged.

Avg. Time Merge from First Commit is the average time from a Pull Request first commit to it being merged.

Avg. Time Merge from First CommentAvg. Time Merge from First Comment - Avg. Time Merge from First Comment is the average time from a Pull Request first comment to it being merged.

Avg. Time Merge from First Comment is the average time from a Pull Request first comment to it being merged.

Avg. Time Merge from First ReviewAvg. Time Merge from First Review - Avg. Time Merge from First Review is the average time from a Pull Request first review to it being merged.

Avg. Time Merge from First Review is the average time from a Pull Request first review to it being merged.

Avg. Time to Issue PR from First CommitAvg. Time to Issue PR from First Commit - Avg. Time to Issue PR from First Commit is the average time from the first commit to creating a PR.

Avg. Time to Issue PR from First Commit is the average time from the first commit to creating a PR.

Avg. Time Merge from First CommentAvg. Time Merge from First Comment - Avg. Time Merge from First Comment is the average time from a Pull Request first comment to it being merged.

Avg. Time Merge from First Comment is the average time from a Pull Request first comment to it being merged.

Avg. Time Merge from First ReviewAvg. Time Merge from First Review - Avg. Time Merge from First Review is the average time from a Pull Request first review to it being merged.

Avg. Time Merge from First Review is the average time from a Pull Request first review to it being merged.

Avg. Time to Issue PR from First CommitAvg. Time to Issue PR from First Commit - Avg. Time to Issue PR from First Commit is the average time from the first commit to creating a PR.

Avg. Time to Issue PR from First Commit is the average time from the first commit to creating a PR.

C

ChurnChurn - 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.

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.

CommitsCommits - It represents the amount of commits done by the developer

It represents the amount of commits done by the developer

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

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

CodingCoding - 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.

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 RateChange Failure Rate - The percentage of builds or deployments that are cancelled or result in failures.

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

Cycle TimeCycle Time - metric 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 |

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 |

D

DeployDeploy - 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.

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 FrequencyDeployment Frequency - How often you deploy code to production.

How often you deploy code to production.

DORA MetricsDORA Metrics - The metrics are composed of the following: | Lead Time for Changes | Deployment Frequency | Change Failure Rate | Mean Time to Recovery |

The metrics are composed of the following: | Lead Time for Changes | Deployment Frequency | Change Failure Rate | Mean Time to Recovery |

E

EfficiencyEfficiency - 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.

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.

F

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

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

H

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

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

I

ImpactImpact - 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.

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.

InvolvementInvolvement - 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;

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

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

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

L

Legacy RefactorLegacy 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

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 ChangesLead Time for Changes - The time it takes for commited code to code successfully running in production.

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

M

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

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

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

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

MergedMerged - Merged is the total number of Merged Pull Requests.

Merged is the total number of Merged Pull Requests.

Mean Time to RecoveryMean 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.

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 TimeMaker Time - Maker Time is the total amount of free time in which an engineer can focus, calculated at 2-hour intervals without interruption.

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

N

New CodeNew Code - Brand new code that does not replace other code.

Brand new code that does not replace other code.

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

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

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

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

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

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

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

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

O

OpenOpen - Open is the total number of Open Pull Requests.

Open is the total number of Open Pull Requests.

P

Productive ThroughputProductive Throughput - It represents the proportion of code without churn.

It represents the proportion of code without churn.

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

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

PRs OpenPRs Open - It represents the number of open pull requests of an engineer.

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

PRs ClosedPRs Closed - It represents the number of closed pull requests of an engineer.

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

PRs MergedPRs Merged - It represents the number of merged pull requests of an engineer.

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

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

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

PR Comments AdressedPR Comments Adressed - It represents the number of comments addressed by an engineer in all pull requests.

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

PR Reviews AddressedPR Reviews Addressed - It represents the number of reviews addressed by an engineer in all pull requests.

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

PickupPickup - 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.

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 RiskPull 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 |

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 |

R

RiskRisk - 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?

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?

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

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

ReceptivenessReceptiveness - 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.

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 MetricsReviewer Metrics - Reviewer Metrics provide a gauge for whether reviewers are providing thoughtful, timely feedback. Reviewer Metrics are: | Reaction Time | Involvement | Inluence | Review Coverage

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

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

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

Review coverageReview coverage - Review coverage represents the percentage of PRs reviewed.

Review coverage represents the percentage of PRs reviewed.

Robust CommentsRobust Comments - Robust comments are comments that have a length over 200 characters.

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

Regular CommentsRegular Comments - Regular comments are comments that span between 100-200 characters

Regular comments are comments that span between 100-200 characters

ReviewersReviewers - Reviewers is the number of reviewers per Pull Request.

Reviewers is the number of reviewers per Pull Request.

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

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

ReviewReview - 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.

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.

S

Submitter MetricsSubmitter 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

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 MetricsSharing 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 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 IndexSharing Index - Sharing Index measures how broadly information is being shared amongst a team by looking at who is reviewing whose PRs.

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

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

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

T

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

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

Technical DebtTechnical Debt - It is the amount of refactoring code done by the developer

It is the amount of refactoring code done by the developer

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

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

Trivial CommentsTrivial Comments - Trivial comments are comments that have under 100 characters.

Trivial comments are comments that have under 100 characters.

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

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

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

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

TotalTotal - Total is the total number of Pull Requests.

Total is the total number of Pull Requests.

U

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

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

W

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

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

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

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

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

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