Should we consider Review Ninja for Code Review?

So there’s a a FOSS project made by SAP called Review Ninja – it is totally awesome. They shared the booth with us at OSCON.

You comment on the PR in Review Ninja and it is stored as a comment on the PR iitself in GitHub.

If you wanna to, maybe try it out when you review PRs. I plan to use it this summer and will write up . my experience. We can even deploy an instance ourself – but I’d prefer we not do that personally – plus we have nowhere to put it.

What are the main benefits it gives you over just doing the review on the GitHub PR?

1 Like

This page has all your questions answered. It’s just sleek. I’m gonna use this summer…so will report back – likely in the form of a blog post.

Their answer to “Why should I use ReviewNinja”:

ReviewNinja gives code review more structure than Pull Requests alone offer. It also provides a status overview so that team members in other departments, such as product management or design, can quickly grasp the state of the project.

It appears to add a voting system to PRs and help with workflow. The problem being solved isn’t clear to me either, @pascal.

We’ll look forward to your blog post, @r0bby!

-Burke :burke:

1 Like

I haven’t yet read up on Review Ninja, but generally the consensus last week at OSCON from major/large open source projects like OpenMRS is that using pull requests alone for code review are insufficient for various reasons. Here’s a good argument for Gerrit, another player in this space, that also came up last week:

1 Like

I actually merge by hand, not using github’s pull request ui…I typically manually squash/cherry-pick…sometimes I rebase. Cherry-picking allows a linear history.