Ben Lloyd Pearson on Dev Interrupted

Thanks for the kind words! I find that most PRs fall into one of these categories: 1. Safe changes that create little to no risk, such as zero-risk resources or PRs from owners of non-production code. These should be approved automatically 2. Standard improvements that create low to moderate risk for production systems. These PRs should go through your standard peer review process before being merged. 3. PRs that touch particularly sensitive or complex parts of the code or that have the potential for significant security risks. These should have extra scrutiny, and you should implement automations to ensure your team has the context they need to properly review the code.