Additionally, the way most pull requests are reviewed is myopic: What changed gets reviewed, but often no one looks at the file as a whole, missing for example triplicate code that should get abstracted away.
kief.yml @kief
22 May 2019
Pull requests add overhead to cope with low-trust situations, e.g. to allow people you don't know to offer contributions to your project. Imposing pull requests on devs in your own team is like making your family go through an airport security checkpoint to enter your home.
1
2
This is one reason why I distinguish "Change review" which is done on PR/MRs and "Code review" which is done on the codebase as a whole in a periodic/incremental manner.
1
1
Replying to @dsilverstone @Lynoure
Though I don't agree that devs on your own team should get to bypass PRs -- Even in a team of excellent engineers, things get spotted by others which would otherwise get through.

May 24, 2019 ยท 8:07 AM UTC

1
Replying to @dsilverstone
I personally have been missing a Definition of Passing from reviews. In one team they did weeks long PR reviews, because it was not perfect in the eyes of everyone yet
1
I think that kind of thing is quite hard to pin down. I tend to use "+1/+0/-0/-1" as a scale, where "+1" is "I like this, it should merge" "+0" is "I think this is okay, if someone else likes it it should merge" "-0" is "this smells bad but I won't block" and "-1" is "Hells no"
1
1
more replies