Wikimedia ran a vote to find which problems are the most annoying to developers (not limited to problems with Phabricator) and this one was the most voted by far, with over one third of the participants voting on it.

Chrome 54 / Ubuntu 14.04. Tabbing through the comment edit form fields looks like this (screenshots are from phabricator.wikimedia.org):

@epriestley Tasks that are invisible to the user show up in Mentions as "Restricted Task". Is that intentional? In most other places such tasks are simply invisible. It is information leak (even if a very small one) and does not seem to provide any benefit.

Here are a few use cases for experienced peers rebasing each other's commits:

• I am reviewing a patch which is OK but I don't like some detail like naming or code organization. It is somewhat subjective and a nontrivial effort to change, so I don't want to force the patch author to do extra work because of my personal preferences, but I am sufficiently annoyed by it that I am willing to do the extra work myself, so I ask them if it's OK for me to change that, and do it. The real work in the patch is still theirs, and so is the responsibility, so 'commandeer' sounds inappropriate.
• a patch needs some trivial change (easy rebase, comment typo fix etc), and the author is not immediately available (different timezone or maybe a volunteer who only has time on the weekends). Asking them to fix will cause unnecessary roundtrip delay and require the author to pay again the cost of resuming the context, setting up the developer environment etc. Also during the roundtrip time more code changes might be merged, requiring a less trivial rebase which might necessitate code review again. So it can be a lot of wasted time compared to just me doing the rebase/typo fix.
• multiple developers working together on a complex patch which touches different parts of the system. This is typical enough in open-source software that the Co-Authored-By commit footer got invented, and would probably happen more at the WMF if support for it in Gerrit would not be so horrible.

Preventing images from being cached in public proxies/CDNs is a reasonable security precaution. I'm not sure what benefit Phabricator's URL randomization adds though. the standard approach would be to stream files through the application and require an authenticated session (with the appropriate permissions), and set something like Cache-control: private so that the browser will cache it but upstream proxies won't. That would fix all the issues enumerated here (except maybe the Safari one - not sure how that's related) while still keep the files unleakable. The only performance impact that would remain is that files cannot be cached in a CDN and they need to be streamed through a lightweight PHP process - that's nontrivial but not huge.

Showing inline bash command snippets containing backticks seems like a pretty common usecase. The only workaround I found is to use the triple-backtick syntax but that takes up more space and breaks the flow of the text.

Shift+click on the scrollbar used to make the handle jump right there (Chrome/Linux but many other browsers/OSes too), that doesn't work anymore. Super annoying on very long pages.

Not sure if this is related, but when adding T2 via the "Create subtask" link, not even T1 will show any notification. (example)

A more specific use case: when I am adding a new task and am unsure whether it fits into a certain project, typing that project name in the search box and middle-clicking would be a convenient way of checking that project's description.

Project names, user names. Admittedly it's not something I would use often, but it did annoy me a few times.

In T4828#55278, @epriestley wrote:

For example, T397 is a duplicate here, but uses different words for everything -- "consider" instead of "suggest/propose", "dedupe" instead of "duplicates", "bugs" instead of "task": basic title-based search would not have found it. My experience was that this was the norm.

One thing I was missing from Mingle and would be happy to see here is to assign CSS style changes to certain field values, e.g. have a "blocked" or a "taken" field and dim the card if it is set. (An alternative functionality to represent the same meaning in Mingle was rows, but as I understand Phabricator boards won't have that.)

In T4863#80491, @qgil wrote:

The mockup in the description shows story points, and we have at least one team currently using Mingle that relies on story points being visible in workboards.