[mstachowiak]

Shameless plug - I'm one of the creators of GitContext (https://gitcontext.com), a code review tool which has drawn much inspiration from Critique and others, and would love feedback from anyone who's interested in kicking the tires. We just launched in private alpha.

We're putting a maniacal focus into the user experience of code reviews, which we feel is overlooked by most tools. Many of the features of Critique that developers enjoy have been included in our first release... - A focus on only the latest changes - A familiar, side-by-side diffing interface - show 'diff from the last review' by default - Tight integration with other tooling - 'Action set' tracking - we allow you to pinpoint and assign line-level issues to relevant team members and track who's turn it is to act - Satisfying gamification - plenty of buttons that go green and even some fun visual rewards for merging

Additionally, we've layered in... - A beautiful, modern UX that provides light or dark mode - Comments that never become outdated and reposition/evolve with the review - Smart version tracking that handles rebases, merges, and force-pushes gracefully - Progress tracking that allows you to see what each participant has left to complete down to the file revision level. - A real focus on trying to get turn tracking right

We're just getting started and have a ton of ideas we can't wait to layer on. If anyone is up for giving it a try, we're actively seeking feedback. If you mention 'Hacker News' in the waitlist form we'll let you in right away.

[spartanatreyu]

Something is going horribly wrong on this page.

Putting an svg filter over the video element is making the page render 1fps a second on Firefox MacOS.

I legitimately thought you uploaded a massive gif as your feature asset instead of a video.

If the effect is always on the video, you may want to just bake it into the video.

Otherwise, you might want to recreate the filter without using SVGs to do it.

[mstachowiak]

Thanks for highlighting, we're investigating and should have a fix shortly.

[spartanatreyu]

Looks like you fixed it!

[mplanchard]

I have the same problem on Firefox on Linux. It is also extremely heavy on Firefox for iOS, causes the phone to heat up.

[aaravchen]

Am I missing some of the features? The GUI does seem to be nicer, but functionally all I see thats added is support for non-blocking comments and explicit opt out of parts of the review. Maybe the visibility of what reviewers have already completed as well?

The "pick up where you left off" is already available but requires you to manually indicate file-by-file when you've completed your review. The personal Todo list is also very present.

What am I missing?

[stavros]

I'll say what I said downthread to someone who made something similar: This costs more than twice as much as GitHub, does it provide twice the value?

[randall]

GitHub's code review is pretty mediocre imo... just left Meta and I miss phabricator. I'm interested to see new stuff, hope I can get off the waitlist!

[stavros]

I definitely agree there, I just don't know if a tool that adds a feature is worth twice as much as the tool that the feature is being added to.

[mstachowiak]

We agree! Thanks for adding yourself to the waitlist, I'll make sure you're granted access

[selcuka]

> This costs more than twice as much as GitHub, does it provide twice the value?

This is not always the right question to ask. One can argue that both products are too cheap with respect to the value they offer, so the relative value between the two is irrelevant.

In other words, if you can afford $X and $2X without even thinking, and if you think even $10X would be a fair value for either, it doesn't matter if the $2X product offers only 20% more value. You would simply want to get the best, even if it's a diminishing return. I believe $9/month/developer can be classified in this category if you are actually doing code reviews.

[mstachowiak]

Fair question. We're aiming to provide enough value for the price we'll ultimate target. We aren't charging yet, but wanted to provide people with some of our rough thoughts on pricing since it's a common question. For now, it's free for folks who want to kick the tires.

[stavros]

I'll probably try it, but there's no way I can get our finance department to pay $900/mo for something we aren't sure if we're going to use. Maybe pricing it as "Free for the first five users, $9/mo/user afterwards" would be much better aligned with the customers' incentives.

[mstachowiak]

Agreed, that's a tough pill to swallow. We envisioned trial period to let people make up there mind, but free for the first few users is another route. We'll noodle it when we loop back to pricing. Appreciate the feedback, it's helpful.

[mplanchard]

Is this a desktop app? If so, is it cross-platform? I couldn’t find this info anywhere on your site.

[mstachowiak]

Sorry for the confusion. It's currently only offered as a web application and only works with GitHub. We are working to expand beyond these limitations based on customer needs / interest. I assume your interest is in a desktop application?

[mplanchard]

I was just wondering! I'm on Linux, so I wasn't sure on reading the web page whether it was something I'd be able to run, and the screenshots looked more desktop-app than web-app.

We use GitLab at work, so I wouldn't be able to use it there, but I use GitHub and sourcehut for some personal and open source stuff. Code review is one of the few things I don't do in emacs, so there remains room for other tools :)

[mike_hearn]

One thing you could try is using a JetBrains IDE. They can do side-by-side diffs, static analysis in the diff view, you can edit directly from the diff viewer and of course you get full navigation and comprehension tools. When I left Google I spent some time trying to use GitHub's code review tools, but they are extremely basic. In recent years I found that with a custom git workflow I could use the IDE as a code review tool and it worked much better than any web based thing.

The trick is to use git commits as the review comments. As in, you actually add // FIXME comments inline on someone else's branch. They then add another commit on top to remove them. Once you're done, you can either squash and merge or just merge. This is nice because it avoids "nit" comments. If you dislike a name someone picked, you just go change it directly yourself and avoid a round-trip, so it reduces exhaustion and grants a notion of ownership to the reviewer.

If you need discussion that isn't going to result in code changes (about design for instance) you do it on the relevant ticket. This also has the advantage that managers who stay away from code review tools still feel like they understand progress.

It helps to use a specific way of working with git to do this, and to have it integrated into your other tools. I use gitolite combined with YouTrack and TeamCity to implement this workflow, along with a kernel-like ownership tree, but it works well enough at least in a small team (I never got to try it in a big team).