[Negative1]

This is way more complex to me than GitFlow with pull requests. As a matter of fact, if you use something like SourceTree for most of the initial steps it's a few mouse clicks. Also, try Gitlabs for your reviews; it's pretty good!

The idea of a more in-depth review is intriguing (we all know this is something that can be improved), but _voting_ on a peer's code just seems like a bad idea. Vote too low, people get insulted and you breed discontent and mistrust. Too high and everyone stays happy until code quality drops. People will either use this as an opportunity to diminish other's, show off or suck up. Sad, but that's human nature.

I know in-person code reviews aren't always possible but adding this disconnect just seems like a bad idea. Would love some honest feedback from people who have actually used it in medium-large scale production.

[clay_to_n]

What appeals to me about the voting scale is that it's well-defined: a -2 means "don't merge yet", a 1 means "looks good to me but I'm not sure that it's ready to merge". More of an enum than a voting mechanism.

It sounds like it removes the ambiguity of when you leave a few comments on a PR but aren't explicit about whether you think it should be merged or not.

[sytse]

Voting at GitLab is mostly thumbs up for good code and leave line comments for bad code. We don't vote bad code down, downvoting is mostly for issues with feature requests that are controversial.