Managing Pull Requests
The problem with producing anything is that you can have something done well, fast, or cheap, and only fantasies exist in the overlap of the three. Developing code is no exception. If you have a team large enough to attend to each potential addition promptly, you'll need an equally large budget. If you ignore unplanned contributions to move fast and break things, you might find your team going back to those ignored suggestions fix what you broke the first time. Pull request best practices help you maintain a delicate balance between the need to be efficient and the need to be effective.
Git On The Same Page
Your pull request best practices may already be somewhere in your Slack. Ask your teams what pull request practices they are using now. Some teams don't use pull request-- an approach that can definitely work with highly experienced developers. Some teams have a system where pull requests go like clock work. Everybody doesn't have to do the same thing, but when the team leads knows what to expect from the others, all can work with each other more efficiently.
Pulling The All-Nighters
Pull requests gather dust for a few reasons. The size and context of the pull request can leave developers deciding to do almost anything else. Developers need to document their commentary and keep pull requests concise. Large pull requests with lots of changes might get resolved faster and easier when broken up into multiple smaller requests.
Idle Pull Requests
The average idle time for pull requests is two days. Quick: what did you have for lunch two days ago? If it took you a minute to remember, or if you don't remember, then how can you expect a developer to remember the context of a pull request they submitted two days ago? Having a set time to review pull requests cuts down on the time your developers spend trying to remember and then explain.
Who's Up?
When something is everybody's job, it's nobody's job. Appoint somebody, or more than one somebody, to own addressing pull requests. Everybody can and should participate in reviewing pull requests, especially the ones with more than 20 changes. But having an designated pull request reviewer means that the work actually gets done. Don't appoint the lead to address pull requests. They're too busy. This person should also not be the person who catches all the other essential but random tasks.
Time After Time
Monitor your cycle time. Your pull requests shouldn't spend days before being picked up or spend days being reviewed before being applied or otherwise resolved. If they are, your team might have too much work or the pull requests might be too large or poorly documented to be applied quickly.
Budget time to address pull requests at the beginning of the project, or you'll waste time trying to find it later. Make a policy to address urgent change, because pull request best practices mean that you'll have to plan for the unplanned. You're also going to have to be realistic about how much work you have in progress. Setting aside this time will also minimize time spent in context switching, because if your pull request person knows that they will have pull request duty at 11 a.m. and 2 p.m., everybody is prepped to chunk their work accordingly, and they're not being pulled off task at random times. If a designated pull request time isn't needed, the time to switch context again will cost some efficiency-- but not nearly as much as dealing with pull requests ad hoc. As with all best practices, pull request best practices operate off of the "better to have it and not need it, than need it and not have it" principle.
It's Automatic!
If a pull request falls in the forest of GitHub, it doesn't make a sound-- but maybe it should. Automated monitoring of pull requests can provide notifications when a pull request is submitted, track the review time, and track the time between review and addition. Your team lead and pull request reviewers will all need this information to improve efficiency and keep developers happy. And isn't that what we all want?