I think in the end we should not expect GitHub to provide the best option here. We should expect them to provide a basic option (which they do) and for sophisticated consumers to pay more for a much better option. Everyone should be shopping for code review tools!
I disagree on this; GitHub should be building the best option here if they have the resources to do so. The fact that the review interface is as basic as it and so prone to accidentally marking the wrong comments as outdated is a major issue (one that other software like Phorge[0] already shows is possible if we're sticking to the realm of "non-mailing client reliant git servers").
Having to bolt extra features on top of GitHub to make it work properly is a shortcoming of GitHub, it shouldn't be an opportunity to build more tooling the customer has to pay for on top of it. Granted, I can see that conversation would get us nowhere given your income relies on selling people features GitHub is languishing on - you have an obvious interest in keeping that feature shitty.
[0]: Phabricator was disabled in 2022, Phorge is the new fork.
"I think in the end we should not expect GitHub to provide the best option here. We should expect them to provide a basic option (which they do) and for sophisticated consumers to pay more for a much better option. Everyone should be shopping for code review tools!
"
I understand this linke of thinking might suit you but I fear it is not as convincing as it sounds to you. At least it's not to me.
Here's how I like to think about it: GitHub is a generalist. They have a big platform with lots of features besides code review, so even though they also have lots of employees they won't be able to focus on code review as much as a dedicated company could. They also have a huge number of users to please so they can't afford to rock the boat too much or make the learning curve too steep.
I think therefore it's pretty much inevitable that if you need a more advanced code review tool you'll end up picking a third party one. Though admittedly, as the founder of Reviewable, that thinking does rather suit me too. ("It is difficult to get a man to understand something when his salary depends on his not understanding it" and all that. :D )
How you do PRs is definitely important, and should be part of a company's consideration here, but remember that PRs are already a layer of abstraction over the SCM. Self-hosting Git is definitely not as easy as setting up a GH account.
Not to mention that you get an easy way to spin up your CI/CD workflows in GH Actions (which of course definitely has its own problems, which there was another popular HN post about recently). There's a reason why it's the default for new companies -- if there was something much better, it wouldn't have the market share it does I think. Familiarity coming from OSS is also important.
Most frequently, I think it's because you want a single platform to store all company code, but not all teams agree on using GitHub PRs vs a more advanced code review tool. Other potential reasons include having access to the other GitHub features: issues, actions, security stuff, the merge queue, etc. You could pull all these together from less-overpriced more-specialized alternatives, of course, but sometimes it's nice to have a single integrated platform even if you decide to replace one of its features.
GitHub is a platform with dozens of tools, I think of it as a basic toolbox. It's great, but if you're hammering nails all day, you should invest in a nailgun. Doesn't mean you don't use the hammer or the wrench in your toolbox, but when you care about one task a lot, you invest in the tool to do that task better
Question: does CodeApprove place related files in closer proximity during review? I would _love_ to have a class and its test next to each other instead of sorted alphabetically. I'm tired of jumping around all over the place, trying to traverse through my review thought process.
I can't speak for CodeApprove, but Reviewable has file grouping capabilities so users can groups files based on anything they want (using a javascript function to do it)
CodeApprove does not have that feature because we don't currently do any smart code parsing to understand what would make a file "related". I think Viezly (https://viezly.com/) does the best job at that.
That's like saying it's OK to expect (say) Ford to make a car with no steering wheel. GitHub basically define the baseline for the entire industry and have millions upon millions to blow on trying to do better.
(OK, Saab did actually do that once but they're weird)
The tail is not as painful as real engineering but as an industry we throw away billions in value every year to dumb processes. There is more to this than just the scar tissue.
It's not just a feature, the model is fundamentally different and much more conducive to delivery, feedback, and happiness.
> We should expect them to provide a basic option (which they do) and for sophisticated consumers to pay more for a much better option
GitHub is fairly feature rich imo, _especially_ when compared to something like CodeCommit on AWS. I’ve been forced to use CodeCommit on client engagements and it’s absolutely horrid. Honestly if your tool supported CodeCommit I’d say the value proposition would skyrocket.
Large OSS feels like a different use case than the big company one, to be honest -- I think that what maintainers care about is vastly different than what companies do. GitHub feels optimized for the former (OSS) as it is today.
