What y'all really want is Google Critique. You just don't know it yet, because you haven't experienced it, as it's internal to Google. The closest public product that I could find is http://reviewable.io (no affiliation) which, while it looks weird/amateurish, nails most of the points which make Critique so amazing. There's also Gerritt, but it's too invasive in terms of workflow, whereas Reviewable integrates with GitHub in a more lightweight fashion.
I have worked in both Google and Microsoft and even though I see how people can be efficient in Critique, I must say I prefer CodeFlow.
In CodeFlow any comment is a floating object with a line connecting it to whatever selection it was created for and you can move it around as you like. You also can easily filter out visible comments by state, author, participation in them.. Features around comparing iterations, marking already reviewed files and similar are the same as far as I remember.
Another reason for my opinion might also be that CodeFlow is probably better optimized for large screens, but this might be caused by the weird Google standard of 80 column limit for source code which I will just never understand in the 21st century where everyone has 24" and up full HD to 4k screens.
I am comparing state of both from 2015 where I worked with both in the same year.
> this might be caused by the weird Google standard of 80 column limit for source code which I will just never understand in the 21st century where everyone has 24" and up full HD to 4k screens
even if you have a big screen, it's still useful to be able to fit two or three files side by side on a single screen. 80 chars might not make sense as a hard requirement for, eg, a c++ codebase, but it's still a worthy ideal to shoot for.
Yeah, I agree, but do 120, not hard 80 limit for every language. I remember C++ and JS code where you wouldn't fit even the for() definition in one line and that just becomes crazy
Thanks for redoing the UI. While evaluating, I really loathed the childish style, and I had problems finding the buttons I need when I needed them. The UI is cluttered and not self explanatory. It was a non-starter for me. That said, reviewable has fans in my immediate surroundings, so the problems are not with the system design.
Thanks, I'll take that criticism to heart. :) Can you expand on "childish style", though? My design philosophy is best summarized as "minimalistic but with touches of whimsy", but perhaps that comes across as childish?
Thank you for putting it together! I switched folks over and we've been paying customers for well over a year now. I can overlook the UI deficiencies when I have proper review workflow, but the problem is that people who don't know the Critique workflow might be put off by the UI. Personally, I encourage them to give Reviewable a good try anyway. Anything larger than a few dozen lines and/or needing multiple rounds of feedback is just untenable in plain GitHub. I can say with certainty, our code would be worse if it wasn't for Reviewable.
Thanks again, I might have to quote you on the home page. :) And yes, the UI is often the sticking point for adoption. I don't know if it's just the style / toolkit (an old version of Semantic UI) and switching to something like Material Design would take care of the problem, or if it's a deeper design / UX issue. A good onboarding flow would likely help as well but I haven't figure out what that should look like yet either. More feedback and advice is always appreciated -- and if you happen to be (or know) a UX expert who knows how to fix it I do have some budget I could throw that way. :)
From my brief play with your demo it's a bit of both.
The toolkit is very small and lacks good definition of elements (both visually in that it lacks contrast, and practically in that I have no idea what is clickable or editable).
The page structure isn't that clear either, where are the column headings? And on my widescreen browser window the isn't a limit on horizontal stretch - I have to play with the browser to find a good width. Also, I can expand code, but how do I shrink/hide it?
Sorry, not going to happen as things stand. A big part of Reviewable's attraction is the tight GitHub integration, so supporting other platforms (BitBucket, GitLab) would essentially require a fork or some pretty heavy-duty abstractions. Either way, future maintenance would become much harder, so I can't build a business case for it. Perhaps if BitBucket or GitLab were larger / growing faster, or if Reviewable was a much larger company with many developers to throw at the problem...
BitBucket doesn't have a large OSS community, but it does have a lot of larger business that need Jira and Confluence integration. So it could be worth it, just the user base isn't as visible as GH.
Definitely something to think about then, since I think larger businesses are the sweet spot for Reviewable and that's where most of the growth has been coming from in the last couple years. Still, forking the codebase _really_ doesn't sound appealing...
Abstractions are sometimes really good for understanding the business. But yeah comes with a price tag and potential mismatch to the real niche (like GitHub add on)
BTW, does anyone where to get better-than-anecdotal data on userbase size and composition for GitHub, BitBucket, and GitLab? And, ideally, growth trends?
The GitLab number tallies with Emily's answer, which gives me some moderate confidence that these numbers are in the right neighborhood. I'm also going to assume that the users-vs-teams numbers are all in roughly the same proportion.
Based one these numbers it doesn't make much sense to target BitBucket unless either 1) they're growing much faster than GitHub (unlikely) or 2) their customers are a much better fit for Reviewable (possible, but it would have to be a truly significant difference in userbase composition). Targeting GitLab doesn't appear to make sense at all (as a business), though perhaps they're growing fast.
It's hard to compare, since Reviewable is an OAuth app and hence needs an install per-user rather than per-org. However, on the page you linked I see a couple apps topping out at 6-7k installs, and most of the rest are in the low hundreds. This doesn't look particularly impressive to me...
Community Advocate for GitLab here. We can't share that data publicly (also because it's hard to track since many are on open source core), but we do have over 100k orgs using GitLab
"edoing the UI is on the to-do list, once the migration from Angular to Vue is done."
Is what makes me uncomfortable about modern webdev. Valuable product work constantly deprioritized by migrations to new frameworks. Magpieing has always been a risk in hobby projects, but in the past there was a smaller torrent of nee things to always be migrating to.
Eh, I don't think it's as bad as you make it sound. It's not "constantly", it's the first major migration effort for Reviewable. And honestly, I probably could've stayed with Angular 1.x for a few more years (it's still being developed, after all), I just got tired of working around its performance issues. There's also 4 years of learning how best to architect an application like this that led to the creation of a Firebase-centric model layer where Vue happened to be a good platform to build on. And even if we didn't switch platforms, a thorough refactoring would've been necessary after many years of accumulated technical debt.
That doesn't seem particularly different that desktop software. Pretend s/he said that once they got to off of WinForms and onto WPF they could iterate on the UI design. or maybe once they upgraded GTK, or whatever.
I worked at Google ~2006-2012. Most of my experience was with Mondrian, but Critique was coming online shortly before I left. I used it long enough that the general "feeling" of using it stayed with me, but not long enough that I actually remembered specific features to copy -- especially since I didn't start even thinking about Reviewable until ~2014. So really it's more of a "spiritual ancestor". :)
I've worked at AWS and Google. CRUX and Critique have similar functionalities. In general there's mostly a 1:1 mapping of equivalent internal tools between the two companies, albeit each with their own flavor.
Having only ever used CRUX (and ReviewBoard prior to it), I'm honestly surprised that most of what is discussed in the article is not common outside of Amazon.
Having used CRUX (and ReviewBoard prior to it), I'm honestly surprised it's considered an okay solution? Maybe 10 years ago it was fine, but the productivity it zaps and bad habits it encourages are a staggering waste of developer time. GitHub/GitLab is light years ahead, to the point where even small shops (can) have better code review process IMO. (Gerrit is decent, too, but the weak UI and interesting process cancels out other advantages is has over GitHub/GitLab.)
What were the bad habits in code review that you were thinking about? I'm stuck with TFVC and the code review in TFS is very poor but I used ReviewBoard about 8 years ago and thought it was the best F/OSS available at the time.
mainly for CRUX and the surrounding ecosystem: it's very hard to protect the main branch from pushes that don't meet approval, that's done afterwards during deployments. this is obviously and horrendously dumb, you really want to catch stuff before it goes in master/mainline, and having to fix this stuff before deploying it also a great use of time /s.
but it gets worse. the UI can't or won't do trivial rebases. so either you upload a new, rebased revision, and get the reviewers to re-review (because stale reviews get wiped), or just rebase, push, and mark as merged. i get you are supposed to review rebases, but this can grind a team to a halt. you're waiting for approvals, but by the time you get them someone else has pushed a new change... a colossal waste of time (edit: especially if you require 2 approvals, which i do think is good practice, and some AWS teams do it).
this also means people are trained to ignore the merge button or expect it to be greyed out. but it might be greyed out for other reason though. in GitHub, you have big green check-marks or red icons to indicate which conditions have and haven't been met (reviewers, CI, merge conflicts). in CRUX, hovering over the greyed out merge button gets you one cause at best (there is a page/tab that shows more detail, but almost nobody looks at it).
obviously it depends on your team, but it requires near constant vigilance to maintain high quality with CRUX, especially with a big team or less experienced devs contributing. process is supposed to make quality easier, not harder!
there are many other smaller issues, but that's the big one IMO. as for ReviewBoard, personally i prefer Gerrit, which itself doesn't have a great UI, but makes up for it in the workflow.
But you actually can setup rules to prevent merges unless certain people/groups have approved. It sounds like you and your team are suffering more from bad code review habits than a bad tool. Devs should review what they are publishing to their peers at least once before actually hitting the publish button. It’s a courtesy to them and their time
I personally love the Crux tool and some of its add ons.
> But you actually can setup rules to prevent merges unless certain people/groups have approved.
As detailed, that only prevents merging via the UX, not pushes to the main branch. Maybe the team does suck, but I still consider it a shortcoming of CRUX et al.
Not to hijack the thread too much (I'm also very curious about the answer -- I'm one of the Review Board founders and these discussions always interest me), but we support TFS these days in Review Board by way of our Power Pack add-on product, if you'd like an alternative solution. I can talk to you more about this off this thread if it's at all interesting to you.
How would I know, CodeFlow is internal to Microsoft. As far as I can tell from public sources, it's trying to solve some of the same problems (keeping track of structured, possibly multi-party and multi-round conversations over revisions), but it's a Windows app, and Critique is really Google's V2 or even V3 of this kind of thing that runs in the browser and is deeply integrated with the rest of their engineering infrastructure. I hope it eventually makes it into Google Cloud, it really is that good.
> How would I know, CodeFlow is internal to Microsoft.
Lots of people have worked for both Google and Microsoft. The article said CodeFlow was good. You said no, Critique is better! But I guess you don’t actually know one way or the other.
Which is too bad. Because it’d be great to hear thoughts from people who’ve tried both.
Maybe what I really want is CodeFlow. Maybe Critique is evidence that I need CodeFlow in my life! It could be that you want CodeFlow in your life, you just don't know it yet.
Seeing that I haven't willingly used Windows in the last decade and wrote zero code for it, I highly doubt it. I would, however, pay for Critique+Blaze+Forge if Google offered it on Google Cloud. It's an incredible force multiplier.
I've worked at both. My memories of CodeFlow are a bit faded but I don't remember it doing anything that Critique doesn't. Critique has the advantage that it's hosted on the web, while CodeFlow was a janky Win32 application.
I worked at both, but I left MS before CodeFlow was created. An earlier version of what is now Critique (called Mondrian) was already in use at Google when I joined, and predated me by several years. There might have been something similar before it, I don't know.
