Objectives and Key Results (OKRS) involve the definition and measurement of progress through specific Key Performance Indicators (KPIs). It’s a regular practice we use at DojoMojo to generate actionable and data-driven insights that facilitate improved decision-making. What gets measured, gets improved.
*Read more about the benefits of OKRs here: https://dev.to/dojomojo/engineering-okrs-mistakes-and-learning-at-dojomojo-41ee
This quarter, we’re tracking the average time it takes for our Github pull requests to be reviewed. Why are we measuring this? Thought of another way, pull requests represent all the meticulous planning and the execution rendered by the product and development teams – furthering your product means merging these new features and fixes.
On top of that, as Dan Baker, Head of Engineering at DojoMojo says, “the less context the reviewer has as to what the developer was thinking when they wrote it, the harder the code is to review. This is beyond a documentation question, and delves into a micro level as to why each decision was made when writing the code.”
The first step: establish a baseline. While Github doesn’t offer native PR statistics, Github does provide webhooks: an API concept that provides real-time information triggered by various events.
Github’s webhook offering is extensive. For our case, we’ll subscribe to pull requests. When a pull request is opened, closed, assigned, edited, review requested, or reviewed, Github will fire a HTTP POST request with a payload of information to a custom route in our backend.
After we setup on Github, we’ll structure a HTTP POST route and a sequelize database table. For us at DojoMojo, the relevant fields are event action, pull request number, owner and reviewer.
We’ll leverage the automatically generated “createdAt” timestamp field to calculate the average time of pull requests opened to closed. Grab all of the pull requests with ‘opened’ and ‘closed’ actions and then calculate the difference between the ‘opened’ and ‘closed’ “createdAt” times.