Performance report for ipython/ipython
Pull request backlog
The pull request backlog presents the number of pull requests processed per month. Even though a month is relatively coarse-grained period for pull requests (where review and acceptance/rejection happen very fast), the backlog view can be helpful to get an idea of the overall activity within the project.
Slow Pull Request lifelines
In this plot, we can see the lifelines of the slowest 10% of pull requests. For this project, the cutoff is 33.265463 days. 552 pull requests where processed slower than that, while 4966 were faster. The line represents the time between opening and closing the pull request. Pull requests whose end time aligns at the right edge of the plot are still open at the time of building this report. Generally, it is considered good practice to avoid having pull requests open for long.
Source of commits
This figure presents the source of commits in your project. The more commits come from pull requests, the more open the project process is to accepting contributions. However, pull requests may be used internally (across project branches) so this might not entirely reflect the actual situation.
Commits from the project community as percentage of total
Percentage of total commits (and trendline) coming from the community. The more commits coming from the community, the more this project is a community effort.
Comments and commenters from the community
Percentage of comments (left) and people that commented (right) coming from outside the project's core development team. The more comments coming from the community, the more welcoming the project is to outsiders.
Project forks: Total and contributing
This is a plot of forks created per month versus forks contributing code back (in the form of pull requests) per month. Ideally, all forks should contribute back. In healty community, the montly number of forks contributing should be increasing, as the total number of forks increases.
Generated at: Tue Oct 22 02:46:33 2019