📘 Waydev Metrics

Active Days- Active days metric represents the number of days a contributor was active, tracking code commited and pull request activity.

Average Pull Request Size- This metric refers to the number of lines of code that were modified and added plus the total lines of code removed. Short pull requests are typically specific. They make one small codebase improvement, one bug patch, or one feature addition.

Average time from merge to deploy (sec)- Average Time from Merge to Deploy metric measures the time it takes for code changes merged into the main branch of a code repository to be deployed into a production environment. This metric is crucial for understanding the efficiency of the deployment pipeline and the responsiveness of the continuous integration/continuous deployment (CI/CD) processes.

Average time to first comment (sec)- Average Time to First Comment metric measures the time it takes from when a pull request (PR) to when it receives its first comment. It helps assess how quickly team members engage with new submissions, which can be critical for maintaining a fast-paced development cycle and ensuring collaborative problem-solving.

Average time to first review (sec)- Average Time to First Review metric measures the time interval between when a pull request (PR) is created and when it receives its first code review. A shorter average time to first review often indicates a more agile and responsive development team, which can lead to faster iteration cycles and quicker issue resolution.

Average time to issue PR (sec)- Average Time to Issue PR metric measures the average amount of time it takes for a developer to issue a pull request after starting work on a code change or feature.

Average time to merge from create (sec)- The Average Time to Merge from Create metric measures the average time it takes for a pull request (PR) to be merged from the moment it is created. This metric provides insight into the efficiency of the code review and merging process.

Average time to merge from review (sec)- Average time to merge from review metric measures in seconds the average duration it takes for a Pull Request (PR) to be merged from the moment of its first review. For flow efficiency, this is an important health metric.

Change Failure Rate- Change Failure Rate measures the percentage of deploys that cause a failure in production.

Churn (%) - Churn metric refers to the code that has been rewritten or deleted in the first 21 days. Churn is used to indicate the level of activity and change in a codebase and can help in understanding the stability of the code. This value is adjustable on the Settings page.

Churn (LoC)- Churn is defined as the proportion of code that has been rewritten or deleted within the first 21 days after its creation. This value is adjustable on the Settings page.

Code Active Days- Code Active Days metric indicates the average days per month a team member makes at least one commit.

Code active weeks - Code active weeks is a metric that measures measures the number of weeks in which a particular piece of code (or set of codes) was actively changed or modified. It can provide insights into the parts of the codebase that are most frequently updated, which may indicate areas of high complexity, frequent issues, or active development of new features.

Code Impact- Code Impact metric indicates the impact of work done related to code. This value follow many aspects as work size, percentage of the work edited to old code, number of edit locations, number of files affected and the severity of changes. "

Collaborative Commits - Collaborative commits refer to a metric that quantifies the number of commits to a repository involving more than one developer. The metric highlights the degree of teamwork and interaction among team members in a project's development process.

Collaborative Throughput- Collaborative Throughput is a metric used to measure the rate at which teams complete work items collaboratively.

Commits- Commits metric measures the amount of individual commits or sets of commits in a codebase.

Commits/Day (commits) - Commits/Active Day metric includes the ratio between total number of commits and total active days.

Cycle Time (sec)- Cycle Time is one of the best measures of an engineering organization’s velocity. It measures the elapsed time from the first commit made to production release.

Deployment Frequency (per day)- Deployment Frequency measures how often code is deployed into production, including bug fixes, capability improvements, and new features.

Efficiency (%)- Efficiency metric includes the percentage of productive code, independent of the amount of code written. The higher the efficiency rate, the longer the code provides business value.

Failed PRs- Failed PRs measures the number of pull request that fail due to reasons such as failing automated tests, being rejected in code review or not meeting coding standards. It helps in assessing the effectiveness of the code review process.

Follow-On Commits - Follow-On Commits indicate how many additional commits Pull Requests require to be resolved from the moment they were created.

Help (%)- Help metric, calculated in percentage, indicates code that has been updated by another contributor, not the one who initially wrote it.

Help (LoC)- Help metric, calculated in lines of code, indicates code that has been updated by another contributor, not the one who initially wrote it.

High-Risk Commits- High Risk Commits metric identifies code commits that are considered high-risk due to factors such as the size of the commit, the criticality of the code affected or lack of sufficient testing and review. Risk is a measure of how likely a commit is to cause problems. It is calculated based on the size of the commit, how the changes are spread across the code base, and how serious the changes are.

Impact- When calculating Impact, each commit is scored on new work, legacy refactoring, helping others, and churn. We also consider the number of modified files and change points. The score relates to team factors like active contributors and average active days.

Knowledge Sharing Index- Sharing Index is a metric designed to assess how well your team collaborates on code reviews. It quantifies the distribution of reviews across your team members and considers factors that promote fair and active participation. A higher Sharing Index indicates a more collaborative environment.

Lead Time For Changes (sec)- Lead Time for Changes measures (in seconds) the amount of time it takes for code to get into production from the first commit made. Specifically, it covers the period from the initial coding (or sometimes from the creation of the requirement) to the final deployment in the live environment.

Low Risk Commits- Low Risk Commits metric identifies code commits that are considered low-risk due to factors such as the size of the commit, the criticality of the code affected or lack of sufficient testing and review. Risk is a measure of how likely a commit is to cause problems. It is calculated based on the size of the commit, how the changes are spread across the code base, and how serious the changes are.

Mean Time To Recovery (MTTR)- MTTR measures the average duration of the system failure recovery time, from the moment the product malfunction until it resumes full functionality.

Medium Risk Commits- Medium Risk Commits metric identifies code commits that are considered medium-risk due to factors such as the size of the commit, the criticality of the code affected or lack of sufficient testing and review. Risk is a measure of how likely a commit is to cause problems. It is calculated based on the size of the commit, how the changes are spread across the code base, and how serious the changes are.

New Work (%)- New Work metric represents new code added to the code base without replacing old code. This value is calculated in percentage and track business performance over time.

New Work (LoC)- New Work metric represents new code added to the code base without replacing old code. This value is calculated in lines of code and track business performance over time.

PR Failture Rate (%)- The PR Failure Rate indicates the percentage of Pull Requests declined or closed to total Pull Requests, excluding Pull Requests in progress.

Productive Throughput (LoC)- Productive Throughput (Lines of Code or LoC) measures the amount of productive code without churn.

Pull Requests Active Days- Pull Requests Active Days metric measures the amount of days that pull requests remain open and actively being worked on before they are merged or closed.

Pull Requests Impact- The pull request impact metric measures how changes introduced through pull requests affect the project.

Refactor (%)- Refactor metric indicates code that has been updated or rewritten after 21 days, enhancing the internal organization of the code without altering the behavior outside of it. This value is measured in percentage and is adjustable on the Settings page.

Refactor (LoC)- Refactor metric indicates code that has been updated or rewritten after 21 days, enhancing the internal organization of the code without altering the behavior outside of it. This value is measured in line of code and is adjustable on the Settings page.

Reviewer Comments / PR- Reviewer Comments / PR metric measures the average number of comments made by reviewers on each pull request.

Technical Debt (%)- Technical Debt refers to the cost of maintaining and improving software over time due to shortcuts or suboptimal decisions made during development. It includes other issues like outdated dependencies, inefficient algorithms and amount of code that should be refactor.

Throughput (LoC)- Throughput, calculated in lines of code, represents the total amount of code of new work, churn code, help others and refactored code, measured in a period of time.

Total Closed Pull Requests- Total Closed Pull Requests metric tracks the number of pull requests that have been closed, either by being merged or rejected, within a specified period.

Total Deployments - The Total Deployments metric measures the total number of times software is deployed to production environments within a specific period.

Total Merged Pull Requests- Total Merged Pull Requests metric tracks the number of pull requests that have been successfully reviewed and merged into the main codebase.

Total Open Pull Requests- Total Open Pull Requests metric tracks the number of pull requests that are currently open and awaiting review, merge, or closure.

Total PR Comments - Total PR Comments metric counts the number of comments made on pull requests within a given period.

Total Pull Requests- Total Pull Requests metric tracks the total number of pull requests created within a specific selected period.

Total Pull Requests Commented- Total Pull Requests Commented metric counts the number of pull requests that have received at least one comment.

Total Pull Requests Merged Without Review- Total Pull Requests Merged Without Review metric tracks the number of pull requests that were merged into the codebase without undergoing a standard review process.

Total Pull Requests Reviewed- The Total Pull Requests Reviewed metric tracks the number of pull requests (PRs) that have been reviewed within a specific timeframe. This metric provides insight into the review activity of a team and reflects their capacity to handle code reviews effectively.

Traceability (%)- Traceability indicates the percentage of commits that are linked to at least one ticket.

Traceable Commits - Traceable Commits metric refers to the number of commits that are linked to at least one ticket.

tt100- Time to 100 represents the time it takes for a contributor to create 100 productive lines of code (code without churn).

Unreviewed Pull Requests- The Unreviewed Pull Requests (PRs) metric tracks the number of pull requests that have been submitted but not yet reviewed. It provides insight into the backlog of code changes awaiting review and can indicate the efficiency of the code review process.

Weekly coding days- Weekly coding days metric refers to the average number of days within a given week that an individual or team dedicates to engineering work like writing code, reviewing other's work, discurss architecture and make commits.

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