| Here's my process: 1. Open a PR when you're ready for review. The PR should have the following attributes, which make PRs fast to review, and reduces the back and forth since the reviewer has everything they need to provide a really good review.
- Be for a single "What" and have a clear "Why". Both of these should be explicitly in the commit message.
- Preferably be a single commit PR.
- Preferably be less than 100 lines of changes. Keep them as small as possible. If you see a refactor opportunity while working on something, `git checkout -b do-the-refactor master` and make it a separate PR. People review +10 -3 PRs eagerly and very very fast, much faster than a +300 -200 PR that contains refactors, fixes and other jibble. 2. Drop the PR into a #channel and immediately switch to doing something else. Your assumption in an asynchronous work environment is that you are an interruptable as anyone else. This means you default to being interrupted and pickup another piece of work rather than expecting someone else to be interrupted. 3. If I don't hear back within 24 hours, assign an individual and ask them to put it in their "queue" of work for doing in the next 24 hours. 4. If there's non-LGTM feedback, then make the changes in a new commit (so it's clearly separate) and after that I jump back on some other work. The take aways are I context switch in favor of not interrupting my team mates. There are plenty of times I need to interrupt them, for help, code design discussions, etc. PRs are not something I need to interrupt people with. You might think this process means it takes a long time to merge a PR, and when looking at a single PR that's true. But I'm constantly working on 3-4 tasks at a time, interleaved, and using the above process I can still ship multiple PRs a day. |