I often see developers perceiving the curation of a pull request as mere overhead. In the worst case this leads them to open incredibly big (thousands of lines of code) pull requests. Do you care about the size of pull requests? Do you incentivise your teammates to open frequent and small pull requests?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (5)
Are the developers on your team responsible for code reviewing each-other's PRs? In my opinion all developers on the team should be code reviewing each-other (vs. having a small number of senior level engineers that are the bottleneck for all code reviews).
As someone who is reviewing code it's much more difficult to review big PRs vs. small changes. If everyone is responsible for reviewing then everyone will understand that pain and be incentivized to open small PRs because they know how it feels to be on the other side of a bit PR review.
Next, set expectations that software can and should be shipped behind feature flags. If your team can adopt this and start following it then it makes smaller PRs easier because code can be merged and deployed without affecting users in production. There's other benefits and reasons that getting your team used to releasing behind feature flags is a good practice but smaller PRs is one of them.
Break big issues into lots of smaller, more specific issues and encourage creating a branch for each issue and then a pull request for each branch. The result is more pull requests to review but hopefully you then know what needs reviewing.
Smaller pull requests are personally more enjoyable to review because I can quickly develop an understanding of what has changed in a codebase, why it has changed, and if it is correct. When I can, I like to run those changes locally on my machine and play around to solidify my understanding of the changes so that I can ensure that I am reviewing and making comments or approvals with the correct assumptions about the code. I think this process of reviewing is a lot easier to do with smaller pull requests.
In regards to incentivizing teammates to open frequent and small pull requests, I think a good approach would be to provide some guideline for PRs and include why smaller pull requests are preferred. I think most, if not all, engineers would be receptive to logical arguments!
My experience is that reviewing that many changes in one go is extremely hard and most likely prone to miss issues. Ideally a software delivery pipeline should automate most of the analysis but human intervention would still be needed to assess the changes as a whole. One solution might be to enforce a pull request size in the pipeline.
I have told someone I wasn't going to review their patch because it was too big. It kind of worked out in that they tried to split the patch, but the patch was too convoluted to really split easily.