Minimize work wastage by analyzing PR data

Here are some reasons why a pull request (PR) may be closed without merging:

• Proof of concept changes: POC changes are by definition intended for collaborating with team members and there is no intention of merging them.
• Outdated PR: If the changes proposed in the PR become outdated due to other changes in the codebase, the PR may be closed without merging.
• Scope changes: If the scope of the task or feature changes significantly, the PR may be closed without merging and a new PR may be submitted to address the updated scope.
• Abandoned PR: If the PR author abandons the changes or does not respond to feedback or review comments for an extended period, the PR may be closed without merging.
• Duplicate PR: If there is already an open PR for the same change or feature, the duplicate PR may be closed without merging.
• Rejected PR: If the code changes proposed in the PR do not meet the quality standards, technical requirements, or development guidelines, it may be rejected and closed without merging.

PRs charts are a powerful tool for engineering managers to track and analyze the performance of their development teams. These charts provide various data points and metrics that can help managers identify trends, patterns, and areas of improvement in their development processes.

One such chart is the PRs by type chart, which gives a breakdown of closed PRs by type. This chart provides insight into the percentage of PRs that were merged, closed but not merged, and closed earlier but reopened. By minimizing the PRs that are not merged, engineering managers can reduce work wastage of their development teams.

It is crucial to minimize the number of PRs that are not merged to reduce work wastage in development teams. Except for proof of concept prs that are created explicitly with the intent of not merging other prs were intended for merging but did not get merged leading to wastage of work. We should check pr by type charts and if unmerged prs are greater than certain percentage than we should have a closer look at the unmerged prs to identify their root cause. It may be indicative of problem in our process for example if we find the prs are not getting merged because of change in scope than we need to make sure that we improve our planning process or if prs are not getting merged due to change in dependencies than we may need to collaborate more closely with other teams. By imrpoving the process we can reduce the likelihood of unmerged PRs.