How my mom helped my team with Pull Requests reviewing

You can also make your Pull Requests fun to work with

Every development process gets out of hand when there’s a time pressure, and to be honest, it is not that uncommon for time pressure to be there ;) If I’d have to do a list of steps sacrificed for speed I think it’d look like this:

“How to speed up development 101”™

1. Documentation? Nah…
2. Tests? We catch up at some point
3. Code review? Ain’t nobody got time for that

The worst part is — once sacrificed- it’s hard for good habits to come back. We’ve tried many times to get back on track but every single time we ended up with nothing. I have never seen it coming that my mom will help me solve this problem.

Let’s look from a different angle

Is my team behaviour much different from me when I was a kid? Let’s face it- when I wanted to play, I threw all clothes into a closet and considered housekeeping done (It looks like nothing changed over time ;))

Then it struck me- what my mom did was really simple. She was always there to repeat what needs to be done over and over again. Sounds familiar? I just have to constantly tell my coworkers what needs to be done... Except it wasn’t what I really needed. First of all, it does not scale very well. I didn’t want to be this unpleasant folk you try to pass walking the other side of the street either. Then I’ve found it…

Pull Request template to the rescue

Wouldn’t it be nice to always remember what needs to be done when opening new Pull Request? We had a documentation living on a Google Cloud just for that but as you can guess it was never used. It was simply too far to reach. Luckily on February 2016 Github introduced Pull Requests templates. They are markdown files that populate descriptions of newly created Pull Requests. It was exactly what I was looking for.

For our project, we’ve created PULL_REQUEST_TEMPLATE file in .github/ folder and we started iterating on its content to the point where the team was happy.

We’ve created its own Pull Request in which we were sharing our thoughts and ideas so everyone could be involved. You can see what we landed on:

NOTE: SJ is a name of our project on Jira so we’ve tried to stick with it with branch naming as well.

Template structure:

• PR naming rules
• PR maximal count rules — this helped us get rid of Pull Requests hanging too long in the queue, waiting to be reviewed
• PR sections — description, motivation, screenshots for easy debugging and context information about why change was made
• Checklist — filled by PR author. Its purpose is to make sure author did not forget about important actions
• Branch naming conventions

Below is a screenshot of Pull Request template in action. Note the fact that <!--- .... ---> are comments and will not be displayed on a created PR.

Awesome results

With this simple file, we’ve achieved more than ever. It was surprising how team work improved by having this constant reminder of things that have to be done.

• We went down from 3 weeks to 2 days for reviews of the most complicated pull requests
• We no longer need to spin up local app for a simple frontend change review— thanks to screenshots in place
• Pull Request description can be used now to create Changelog
• Team members write tests — they don’t want to be judged for leaving unchecked “I have added tests…”

If you enjoyed this story please hit 👏 button so others find this article too. You may also be interested in the way we automated our code review process.

We can also be friends on Twitter ;)