|
|
|
|
|
|
by jlund-molfese
1331 days ago
|
|
|
My team posts their PR reviews in our team slack channel. Which bothers the totally async purist in me, but we’ve found it to be a good middle ground between waiting for reviews requested via GitHub email and actually pinging someone. If something’s super complex, and I don’t feel like it’s the submitter’s fault, or even if I’ve got a PR where I realize the code I’ve written isn’t optimal, and async feedback would be too slow, I’ll usually schedule a meeting on someone’s calendar, giving them at least a day of notice. But otherwise? If I can’t understand what’s going on without too much difficulty, that’s on the PR submitter to improve their code readability through structuring, naming, comments, or as a last resort, external documentation imo. So I see not having the original submitter involved as a feature. Who knows if they’ll be around when you have questions about the same code in 2 years? Is someone going to document everything that was said in the “over the shoulder” review? That being said, the work I do isn’t anything cutting-edge. More complex code justifies more involved review practices. |
|
|
Why don’t you install the GitHub Slack application? It will tell you immediately when somebody asks for a review and it has other useful functionality as well.