Show HN: Crocodile - Better code review for GitHub
This is cool! I&#x27;m happy to see more options in this space.<p>The best code review tool I&#x27;ve ever used was a tool at Google called Critique.[0] They&#x27;ve open-sourced it as Gerrit[1], but there are sadly no hosted versions available for under $15k&#x2F;yr, and it&#x27;s complicated to self-host.<p>I&#x27;ve been using Reviewable, and my experience has been good not great. Github&#x27;s native code review has caught up a bit, but Github&#x27;s review tool falls apart if your review lasts more than one round.<p>Here are my gripes with Reviewable:<p>Steep learning curve - Every new developer who joins the team spends their first few reviews being confused and frustrated by Reviewable.<p>Performance - Reviewable has awful performance. It takes about 10 seconds to load a code review. It seems like it&#x27;s doing some odd websockets stuff where sometimes my &quot;connection&quot; to Reviewable will drop and I can&#x27;t add comments. I&#x27;ve never experienced this with any other web app. It&#x27;s gotten better over the last few years, but it&#x27;s still annoyingly frequent.<p>Complicated configuration - I just want the reviewer to be able to hit an &quot;LGTM&quot; button to mark their approval. Reviewable&#x27;s decision about when a PR is approved is based on this complicated function combining whether the reviewer typed the text &quot;:lgtm&quot;, how many people looked at the review, whether they also hit the approve button. Each repo has its own configuration, and I can&#x27;t make org-level changes without changing every repo one at a time.<p>Excessive permissions - This might be a Github thing, but you can&#x27;t grant Reviewable permissions to a particular private repo - you have to grant it permissions to <i>all</i> of your private repos. Several developers who join my team need to create a dedicated Github account to avoid exposing their other private repos to Reviewable.<p>Thread state is unclear - The options are &quot;discussing&quot;, &quot;satisfied,&quot; &quot;blocking,&quot; or &quot;working,&quot; and it&#x27;s not obvious who&#x27;s supposed to move the thread to what state at what point.<p>No development - I&#x27;ve been a paying customer of Reviewable for about 7 years, and I can remember only 1-2 minor features that have been added during that time. They haven&#x27;t updated their blog[2] in 6 years, and they&#x27;ve never communicated with me as a paying customer to tell me anything they&#x27;re doing.<p>I checked out Crocodile, and it looks like it has potential. I&#x27;m not sure I&#x27;d pitch it to my team to switch yet. Here are some of my thoughts:<p>* When do the reviewer&#x27;s comments become visible to the author? One of the must-have features for me is that both author and reviwer(s) can prepare a set of notes, but they&#x27;re not visible to anyone else until they hit &quot;publish&quot; to share them with the team. Sometimes I make comments in one spot, and then as I read more of the code, I revise a previous comment. If all my comments publish immediately, I can&#x27;t revise comments like that. Github, Reviewable, and Gerrit all support a flow of preparing comments and then committing them in a separate step.<p>* Crocodile touts the floating thread thing, and I&#x27;ve never used a tool that has it, but it doesn&#x27;t seem better to me. Inline comments do break the flow, but floating comments actually cover up the code and prevent me from reading it. I see I can close threads, but I can&#x27;t figure out how to get them back.<p>* Being able to comment on character-level granularity is cool!<p>* I think your thread state is better than Reviewable&#x27;s, but I&#x27;d prefer an even simpler model where threads are either &quot;open&quot; or &quot;resolved.&quot; When an author responds to a comment, the default action is to resolve it, but the author can override the default and leave it &quot;open&quot; if their comment is asking for clarification rather than declaring a fix. The reviewer can reopen a thread if they feel that the author has misunderstood the note. 95% of the time in my reviews, the reviewer makes a note and the author resolves it, so having a whole extra confirmation phase for that last 5% feels unnecessary when the reviewer can just reopen it instead.<p>* Ditto for review state. The only two states I&#x27;ve ever needed for a code review are &quot;pending approval&quot; and &quot;approved.&quot; I&#x27;ve never wanted to mark a PR as &quot;rejected&quot; unless it&#x27;s just a spam submission from a stranger on an open-source repo, and even then, I&#x27;d close it from Github rather than my code review tool. The worst I&#x27;ll do to a teammate is withhold approval until they address my notes, but I&#x27;d never mark it as &quot;rejected.&quot; I don&#x27;t need an explicit state for &quot;pending review&quot; or &quot;waiting for author&quot; because if the author is the last commenter, it&#x27;s implicitly pending review.<p>* I like that there&#x27;s a view of all the comments at once. I like to review all my comments before pushing them to the author.<p>* I&#x27;d like a way to mark a comment as &quot;no action required&quot; when I just want to say something nice[2] about the code that doesn&#x27;t require action from the author.<p>* I couldn&#x27;t understand the &quot;iterations&quot; UI control. It&#x27;s not obvious to me what the different circles represent.[4] Once I compared two diffs, I couldn&#x27;t figure out how to compare to the the full PR to the base branch (i.e., all commits aggregated). I think it&#x27;s replicating a control that Reviewable actually does pretty well, so I recommend giving it a look for inspiration.<p>* It looks like I&#x27;m only allowed to make code-level comments, but I&#x27;d like to make review-level comments as well for high-level notes about the review as a whole.<p>Hope that&#x27;s useful. I&#x27;m very interested in code reviews, so if you want to do user interviews, feel free to reach out. You can find my contact info through my HN profile.<p>[0] <a href="https:&#x2F;&#x2F;abseil.io&#x2F;resources&#x2F;swe-book&#x2F;html&#x2F;ch19.html" rel="nofollow">https:&#x2F;&#x2F;abseil.io&#x2F;resources&#x2F;swe-book&#x2F;html&#x2F;ch19.html</a><p>[1] <a href="https:&#x2F;&#x2F;www.gerritcodereview.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.gerritcodereview.com&#x2F;</a><p>[2] <a href="http:&#x2F;&#x2F;blog.reviewable.io&#x2F;" rel="nofollow">http:&#x2F;&#x2F;blog.reviewable.io&#x2F;</a><p>[3] <a href="https:&#x2F;&#x2F;mtlynch.io&#x2F;human-code-reviews-2&#x2F;#offer-sincere-praise" rel="nofollow">https:&#x2F;&#x2F;mtlynch.io&#x2F;human-code-reviews-2&#x2F;#offer-sincere-prais...</a><p>[4] <a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;3ZhDAR1.png" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;3ZhDAR1.png</a>