729
Merge then review
(programming.dev)
Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don't let code become stale.
I kind of with the sentiment. Review pre merge though, but only block the merge if there are serious faults. Otherwise, merge the code and have the author address issues after the merge. Get the value to production
This is some poe's law shit. I can't tell if you're serious or just committing to the bit.
Sorry about the confusion. It's not sarcasm. I'm just sick and tired of people blocking my PR because of an argument about wether the function should be called X or Y or Z or D
Ah. Yeah those kind of nitpicks are annoying. We try to specify when comments are blocking or non blocking on reviews.
But I definitely block a lot of reviews over no tests, bad tests, no error handling, failed linting. And the occasional "this doesn't do what the ticket asked for"