7 min read
Sometime ago, a colleague expressed concern about the time investment required for reviewing code on Github. This prompted me to reconsider their approach and prepare a new solution, which I wanted to send to Github.
I will primarily focus on Github's pull request, as that was the major pain point. The objectives are as follows:
Github - is a developer platform that allows developers to create, store, manage and share their code.
Pull Request - A pull request is a proposal to merge a set of changes in code from one branch into another.
About pull request reviews - GitHub Docs
I've used Github a few times for projects, but I'm not an everyday user. So, I started with some research. After gathering feedback and conclusions, I moved to the design phase. Finally, I tested the solution.
<aside> 💡 Previously, as a designer, I used Sketch software with the Abstract repository. It's quite similar to Github.
</aside>
In this project I used Double Diamond Process.
I like to learn from users. So, I spoke to three developers who use Github. I asked them about their experiences with the software, focusing on pull request reviews. I wanted to understand their process, insights, and any issues they faced.
I made a user flow from my interview notes to better understand the whole process. Here are my findings:
Full user flow: https://miro.com/app/board/uXjVN3wgjTA=/?share_link_id=259547882722
I had a very interesting discussion about the modal "Finish your review". In this modal, there are three options to finish the review: approve the pull request, request changes, and submit comments. One developer never used the option "Request changes", because when something is wrong, he adds comments and only if everything is correct he uses "Approve". His argument was that there needs to be at least one approval, so if nobody approves then the person who created the pull request can't merge it, so there is no need to click "Request changes".
Finish your review modal
I've collected all the issues related to Pull requests. I included everything because reviewing “Pull request review” is part of Pull request. To understand the deeper issues, we need to see the bigger picture. Here's what I found: