I would like to see a more pragmatic approach to PRs than the Github esque red barrier of doom you see when you enable branch protection and minimum number of r

I would like to see a more pragmatic approach to PRs than the Github esque red barrier of doom you see when you enable branch protection and minimum number of reviewers. I trust my team to judge if their change is trivial enough that it doesn't need a second review. As some others have said, if you're using PRs _sometimes_, the cost of running tests even for trivial changes is minimal, so I'd lean towards show and ask, rather than ship. That being said, I wasn't massive fan of the comparison to continuous integration. At least, I've never used it in that sense. To me, continue integration is the practice of continuously testing your main branch against your dependencies and always testing changes when they are made. Ideally, dependencies are continuously updated too (at least in the case of apps). This is somewhat orthogonal to the code development and review practices that lead to code being on the main branch in the first place.