This panel is focused on metrics related to Pull Requests merged. As GitHub API does not always identifies merges, we based the panel directly on Git data.
The idea behind the panel is having a look on how community performs and evolved merging Pull Requests. By using this panel we can identify trends and analyze behaviours of specific organizations, projects or repositories.
GitHub API give us information about pull requests merged from the interface or the command line. However, there are some cases in which GitHub is unable to identify a merge. The usual case is a merge done after rebasing through the command line. In that case, GitHub has no way to identify the merge (see Sigils#297). For that reason we decided to build a panel relying directly on Git data, using some basic filters to identify merges. If merges follow an homogeneous pattern, it should be possible to identify them by filtering. This could be not 100% accurate, but it is reasonably flexible to be updated to specific communities or repositories.
A filter is applied within each visualization to get only those commits that we consider as “merges”. We consider a commit as a “merge” if satisfies at least one of the following conditions:
Filtering by Organization and Project is allowed by using the top left corner widget.
Number of commits and number of authors are shown next to filtering widget. These are global numbers to have an idea about the amount of data we are visualizing with current filters. These metrics are also shown at the right hand side, within repositories table. This provide a quick and comparable view of each repository.
Evolution of Pull Requests merged is almost centered in the panel, between global numbers and repositories table. Each bar shows the count of merged Pull Request in a particular time frame (depending on the period selected in time picker, on the top right corner, it could be minutes, days, weeks, months, etc.). Yellow line represents the trend corresponding to the bars providing an insight on the current status of merges for the active filters. The meaning of the trend could strongly depends on how the data is filtered. For example, if we are looking at a new repository only, we could expect having a positive slope, as community is probably getting bigger and number of contributions increase. On the other hand, an old repository could have a negative slope just because it raised its higher peak some time ago and now it travels towards stability. Finally, global numbers for an heterogeneous set of repositories could lead us to a stable trend because of the combination of the different behaviours from different repositories.
Finally, a short text is shown at the bottom to explain the basics needed to understand the panel.
Edit this doc