The longer a Pull Request (PR) remains open and unmerged, the further the code of the base branch can diverge (with other contributors making changes to it in the meantime). Therefore, PRs that are open for long periods of time can lead to more complex and time-consuming merges into the base branch. Smaller PRs might be easier to review and merge quickly and have been linked to increased productivity.
In cases where there are multiple simultaneous long-running Pull Requests (PRs), the challenge of merging the code within them is multiplied. There might be dependencies between the individual features in the PRs and each merge of a PR leads to changes that again need to be considered in all other open PRs, see also "Merge Hell".
The more Pull Requests (PRs) are open at the same time in a Sprint, the fewer contributors might be available to get a single PR ready for merging. Depending on the team setup and the context, additional PRs with smaller scope that can be finished (e.g. tested and reviewed) more quickly could ease merging.
Pull Requests (PRs) can facilitate discussions and reviews of proposed code changes. Interactions with the PR by contributors drive development progress. However, long-running discussions with many comments can also indicate potential problems and confusion related to the PR that may slow down the development process.
This visualization shows the overall amount of reviews, review responses, reactions, PR comments and other team-related timeline events.
The faster a Pull Request receives feedback, the faster it can be improved and eventually merged. This visualization shows how long it took for PRs to receive an inital interaction by somebody other than the author. It's can also be very motivating to receive an intial comment celebrating the creation of a new PR with exciting changes!
Improvement suggestions related to specific code areas may be best handled by a structured Pull Request review, which can be accepted, rejected and discussed. This visualization shows how long it took for a contributor (other than the PR author) to provide a first review after a new PR was opened.
The point in time when code changes are committed shows when contributors were active. The work times of contributors can influence how others can interact with new code, comments or questions. Shared work times in teams may be beneficial for responsive communication and collaboration. Work times that are spread out evenly may contribute to continuous development.
Be aware that the commit times visualized here are not equivalent to the time when these commits where shared with others, i.e. pushed to a shared branch.
The guiding principle of "Check In Early, Check In Often" should ideally motivate contributors to have frequent checkpoints in case of errors, to document their work, to allow feedback and to integrate with other code.
This visualization shows how many commits were contributed on average and how many changes (sum of additions and deletions) these contained.
Issues represent the open work items to be completed. The clearer the work to be done or the feature to be developed is described the easier it is to implement it to an agreed standard. Extremely long or short issues might both not be ideal for contributors to work on, either requiring a split into multiple smaller issues or additional details.
This visualization shows the size of issues as measured by amount of characters in the issue body.
The size of an issue description can influence how likely it is that an issue will be worked on. Both very detailed descriptions (that might take a lot of mental energy to understand) as well as very brief ones (which might lack critical details) can be demotivating. The abstracts that summarize complex scientific papers are usually about 250 words long (about 1200 characters). Concerning Agile software development processes, there has been the idea that a User Story expressing a requirement in an issue should fit on an index card.
Issues often represent the primary work items, describing the work to be accomplished in a team. The time that new issues are submitted can influence how the team works. If issues are submitted in shared team work hours, they may receive faster feedback or can be immediately worked on if they are urgent.