This report shows you the average time a pull request takes to
go from created to completed. This metric is interesting on a couple
sides. If you see the average time is really short, something in minutes
maybe, then you may start to question, are your PR Reviewers actually doing a
review? What are they doing to approve this Pull Request? Are they just
rubber-stamping things? On the flip-side, if the average time is really
long, something in days maybe, then you may start to question if your PR
process and reviews are acting as a bottleneck in your team, slowing their
velocity. Either way, this helps give you a little insight in to
how this repository is going. What Branches are Pull Requests happening for? |
Depending on your branching strategy this report will give you a
little vision in to how your team is working with those branches. So if
you're following a gitflow branching strategy you'd likely expect a larger
number of Pull Requests against your Develop branch. So what really is
the Ratio of PRs to Develop vs. Master? How many updates are you generally
doing before you release something? This graph will group branches in
folders for you, so if you're organizing your branches in to things like
"release" and "hotfix" you can start to see just how many
bug-fix PRs are happening against your release branches in general. Does
this repository have a much higher number of those types of PRs versus other repositories?
Do we never PR bug fixes in to our release? Is this repository only ever
following a Pull Request process on code to the master branch? Any of those
behaviors are fine and may be the process you intend, but this chart will start
to confirm that that behavior is actually what your team is following. Who is approving all of the Pull Requests? |
Ever want to see who is doing all of your pull request reviews?
Or want to see how many Pull Requests are being completed without a Pull
Request approver assigned? Do you have a couple of lead developers charged with
doing the bulk of your reviews? Are they actually doing them? Are they
overloaded? is your team taking time and doing peer reviews? are things spread
out as you expect? This report helps you see what's happening, who's doing the
reviews, and how many are going through without a review. This can help get a
quick insight in to that activity. How are your optional reviewers being used? |
This report will graph out the review stats for the people
assigned to your Pull Requests. If you had optional reviewers added, are
they all given time to review things? Is the team moving forward without all
the reviews? Or are you adding too many optional reviewers? This chart will
show how the approvals are going. If you start to see large trends in
"Did Not Vote" maybe you start asking about why PRs are being
completed without giving everyone time to review, or maybe you ask if your team
is adding people un-necessarily? However this is going on your repo, you now
how some stats to start looking in to how the team is dealing with Pull Request
reviews, and how you might improve either the quality of the reviews, or the
quantity of things your team is asking of each other. Are the Groups you expect to review things getting to their
reviews? |
If you have some groups or teams assigned as your reviewers, you
may want to get a view of if those teams are doing their reviews. This
report is like the individual report, above, but now at the Team or Group
level. So if your Pull Request process assigned groups, either required
or optional, to your Pull Request, now you can see what's happening
there. Are the Optional groups reviewing things? How often? At my client,
we have assigned the Application Security team as a optional reviewer to all
the Pull Requests, but that team started wanting to see how many reviews they
actually participated in, they didn't really have any good idea of that before,
but with this chart they will be able to see just how many they were a part of. So that's it, that's the new extension. I hope you see
some value there, I hope maybe this can help answer questions and give you a
little insight in to how the team is dealing with code. I think that
there is some good power in the data, it may confirm that your team is doing
the things you expect, and that's great to have the power to confirm. Or
it may start to give you some ideas on where you can tweak your process to give
you some better outcomes. Hope you find it useful. |