When we'll be willing to maintain an installation of Phabricator different of upstream (something Phabricator helps with a configuration allowing to load extra classes), I can write a quips application.
Actually, I want it too for another Phabricator install I maintain.
But it's not wise to add a maintenance cost (rebase a production branch against the master branch each time we upgrade, even in a scenario with virtually* no conflict) before a real need occurs.
So I offer to delay this bug as long as we don't have any other customization need, and when we have, go for a quips application.
(*) at worst, on three Phabricator installations I maintain, when we have static resources changes such CSS customizaton, the Celerity map is to be regenerated.
I'm not comfortable with the Dzahn plan. Quips were added in a very particular and precise context, for a very narrow use, for a very restricted diffusion.
The context were the MediaWiki development process, the narrow use is to be sometimes published of the top of bug tracker, the very restricted diffusion is this is only visible on the bug tracker.
So I've some issues with the idea to convert them to memes.
Tthat also go for bash.org mass upload idea of Nemo, especially as that would violate the spirit if not the law (as it's covered by short quote right) of Freenode rules to not publish public logs and some quotes come from IRC.
When we'll be willing to maintain an installation of Phabricator different of upstream
This is not an option, we're forced to; it's just a matter of what will be our first local application.
features which are aimed at a different group of users (like students, casual projects, or inexperienced computer users) may be harder to get upstreamed
Footer to be less interface disruptive, with an experimental option for .phabricator-crumbs-view (the top bar, where you have the application icon and the monogram of the current element).
A separate dedicated application would perhaps be better here, though in ways it feels a bit overkill to me.