I think mouse users don't generally suffer from this problem: by default, MacOS always shows a scrollbar in all contexts if you have a mouse plugged in to your computer.
A customer of mine was surprised to see some extra VMs in vSphere a few days ago. He never tried to scroll a list somewhere in the app and always missed the extra content because his Mac doesn't display the scrollbar. He has a laptop, so no mouse. I tweaked my Gnome desktop to always display a transparent scrollbar (only the outline is visible) so I could see that the list had extra elements.
By the way, vSphere is part of the problem. It's one of those web applications that try very hard to look like a desktop application. It doesn't use the standard HTML behavior of building a page that scrolls. It clips everything at the borders of the screen. Ironically that reduced functionality probably cost them a lot of developer time.
Not only does it not show the scroll bar by default, but (not sure if this is a Chrome or Mac issue), when it does show up during a scroll operation, you have to have great reflexes to grab it with a click if you want to.
This is not (and has never been) the behavior of Phabricator.
See <https://secure.phabricator.com/T7447> for discussion of why this feature can never work the way you think it should work in the general case and why I believe other implementations, particularly GitHub's implementation, make the wrong tradeoffs (GitHub simply discards comments it can't find an exact matching line for).
If you believe this feature is possible to implement the way you imagine, I invite you to suggest an implementation. I am confident I can easily provide a counterexample which your implementation gets wrong (by either porting the inline forward to a line a human user would not choose, or by failing to port an inline which is still relevant forward).
I don't need perfect, I just need good. GitHub and GitLab both have good implementations as well as every other good code review system I have used. GitHub annoying tries its hardest to hide the "outdated" comments but GitLab has the option to keep them open (they are no longer visible in the code, but remain on the discussion tab)
So I appreciate your opinion that it is impossible, but as a reviewer I much prefer when the tool tries.
GitHub's implementation does not do what you claim it does. GitHub has no behavior around porting and placing comments (while Phabricator does), GitHub just hides anything it can't place exactly. See my link above for a detailed description of GitHub's very simple implementation. I believe this is absolutely the wrong tradeoff.
I use GitHub every day, I've definitely seen it preserve some comments. Sure, it drops a lot. But I still prefer this to dropping them all, or showing the comments on the wrong lines.
I mean that GitHub does not "try", in the sense of looking at the interdiff, doing fuzzy matching, trying to identify line-by-line similarity, etc. It places comments only if the hunk is exactly unchanged and gives up otherwise.
Phabricator does "try", in the sense that it examines the interdiff and attempts (of course, imperfectly, because no implementation can be perfect) to track line movement across hunk mutations.
My claim is that all comments which GitHub places correctly, Phabricator also places correctly. And some comments which GitHub drops, Phabricator places correctly (on the same line a human would select)! However, some comments which GitHub drops, Phabricator places incorrectly (on a line other than the line a human would select).
So the actual implementation you prefer is not one that tries, but one that doesn't try! Phabricator could have approximately GitHub's behavior by just deleting a bunch of code.
That's perfectly fine: many other users also prefer comments be discarded rather than tracked to a possibly-wrong line, too. I strongly believe this isn't a good behavior for code review software, which is why Phabricator doesn't do it -- but Phabricator puts substantially more effort into trying to track and place comments correctly than GitHub does.
In particular, see <https://secure.phabricator.com/T7447#112231> for a specific example which I believe GitHub's implementation gets egregiously wrong, by silently discarding an inline which is highly relevant to discussing the change.
In my view, refocusing the roadmap on only requests from paying customers was possibly the best change I've made for the health and longevity of the project.
Let me say up front that I'm a die-hard fan of Phabricator but not a paying customer. I have no idea how you've managed to build and maintain that project, it's amazing.
Paying customers hire developers, and developers always, always create pressure within their organizations to use the tools and software that the developers are most familiar with. A few developers in this thread have mentioned some things they've struggled with; I've spent a lot of hours reading Phabricator documentation, sussing out Conduit, trying to learn how to use the whole system well, and there are still lots of gaps in my knowledge. When Phabricator becomes too different from the workflows that developers are accustomed to elsewhere, and it isn't immediately obvious that those differences make it better than the alternatives, then they're going to pressure their organizations to not use Phabricator.
Developers furthermore are always looking for ways to build their resumé. The further away Phabricator falls from being used in big, well-known, popular software projects, the more it becomes a hindrance to resumé-building. A developer can add GitHub or GitLab familiarity to their resumé for extra credit, and GitHub public profiles are a good way to say, "Hey look, I write and ship code on a regular basis". If I'm trying to get hired, and I want to learn about integrating CI, I might have to choose between GitHub Actions or Harbormaster. One of those is far, far more valuable for resumé-building than the other.
I can't argue with your focus on paying customers, but if your developer community isn't big and healthy, your paying customers will eventually not be, either.
Open source projects generally want an exact feature-for-feature copy of GitHub that looks and works exactly like GitHub, except open source.
If Phabricator was this, there would be no reason for paying customers to ever choose it over GitHub, because paying customers generally do not care if a solution is open source or not.
But the bigger impact of this change was not a product impact at all: it was that interacting with paying customers is something I generally enjoy and feel good about, and interacting with open source users is something I generally hated and felt miserable about.
For whatever reason, Phabricator attracted a large number of users who wanted to argue with me about every technical decision, insist that whatever feature they wanted should be the highest upstream priority, suggest I should pay them for their "valuable suggestions" because they are an important CEO, take offense when I asked them to please please please read the documentation and provide reproduction instructions, bump every open task asking for status updates, etc. This stuff had a huge net cost to the project and only got worse over time as the project grew.
Writing off open source installs allowed me to stop dealing with all of this.
Can you point me at any data which supports this? It seems like it should be true, but GHC didn't appear to see a year-over-year increase to contributors when they switched from Phabricator to GitLab in December 2018.
I added another comment to https://news.ycombinator.com/item?id=23686803 about case studies we hope to do about this. So while we don't have any to point you to today, we hope to have some in the near future.
Another thing that we hear from people considering a move to GitLab is that they really like how fast GitLab moves (one release per month!), and how it works with the community to keep improving the product. I recently joined as the Sr. Open Source Program Manager as part of the Community Relations team, and we're thinking a lot about how to continue to improve the experience for our community.
(I'm not sure this is a fair comparison, and am not aware of other possible changes to GHC during those years, and bear in mind that I'm a highly biased party.)
Can you point at a project which made a switch like this and saw an actual significant change in contributions or contributors afterward?
I'm not the OP. However, speaking from my own experience using Phabricator for the first time: I wanted to send a small pull request that fixed wrong mouse cursors being used on Chromium-based programs. The fix was literally symlinking a couple of files. This issue was on Breeze_Cursors from KDE, by the way.
It took me half an hour to read the KDE documentation on how to contribute, then set-up my workflow, learn how to use arcanist; to only then, submit the pull request. Thankfully my pull request was accepted right away, because had the developers requested code changes I would probably have to spend some more time having to deal with arcanist again.
I'm not gonna lie, having to use a totally different workflow from the ones I was used to (Github, Gitlab and the like), just to submit a small change, was a little frustrating. Ah, one more annoyance (although not related to code): The two-factor authentication system used in KDE's Phabricator is _so stupid_ that I wish I hadn't seen it.
I can totally relate to this. In fact, just a few months ago I complained here about the steep entry bar for KDE projects.
Now, ever since moving to Gitlab not only was I able to successfully contribute, but I effectively became a co-maintainer of one of the projects. We also had some pull requests from some "hit and run" coders previously unknown to the project.
It's 2020, nobody wants to waste hours to learn how to contribute to an open source codebase. I can't think of a bigger deterrent than a complex, unorthodox approach that KDE had previously used.
> It took me half an hour to read the KDE documentation on how to contribute, then set-up my workflow, learn how to use arcanist; to only then, submit the pull request.
Couldn't the same argument be made for having to learn a language in order to even contribute code to a project? Learning how to collaborate using different systems isn't really different than having to learn different languages, conventions, or code styles to contribute to different projects.
Just to add to this discussion, I work at GitLab and we have it on our roadmap to write some case studies about open source projects using GitLab. It's great to hear people's personal stories with regard to contribution being easier, and we hope that the case studies will serve as another reference for people considering a move to GitLab.
Interesting! This isn't how I remember things at all. Do you know where you got this sense of things from, specifically?
In particular, do you remember what gave you the impression that Facebook "overinvested" a large amount of effort into Phabricator, that I developed and open sourced Phabricator primarily to get promoted, that I built Phabricator because of scaling concerns, or that the primary value I provided to Facebook during my employment there was just in not starting a competitor?
