There are many ways already to achieve this, for instance editing the description of a project to highlight the important tasks, using workboards, or using sub projects when they come about. The use case here is a bit to narrow for upstream in my opinion, especially if we resolve T5558 in a scalable way

See also T3725.

There are two use cases where this is still helpful: when talking about the task on a mailing list or otherwise outside of phabricator, when cross referencing tasks or projects on the other pages. The goal here is to provide an easily referencable object / task / bug / project: not just for pure organization.

So you want hashtags for other objects, essentially?

If I understand how hashtags are used for projects, than pretty much yes.

(edit: I basically I want to be able to use a memorable name instead of a number for objects, wherever a number might be used)

We prefer to generalize features that solve a large number of problems, for instance I'd like hashtags for Conpherence Rooms, and maybe it'd make sense to have /tag/ as a not specific to Projects notion. Unclear if people would confuse a Room tag from a Project tag, from a Task tag, but seems maybe worth exploring. @epriestley?

I totally understand that, and agree with that notion. This is one of the reasons I like phabricator so much compared to other tools.

The key for me though is that I be able to use the tag/hastag/alias/whatever as a reference wherever I'd normally be able to put a number: this way, for some some bugs/projects/tasks/diff/whatever, it isn't important to remember the exact number.

I'm not really convinced that this is hugely valuable, although it seems like it might plausibly be worth building at some point, maybe.

I definitely don't want to overload hashtags. We could come up with some other "alias" syntax instead.

One use case this potentially enables is using these aliases as variables: you could have things like %current, which you rebind to different objects over time. Then you can query for members(%current) or whatever. But I don't really see any use cases for this, either. Releeph sort of uses it but I think I just want to rip that out.

Generally, I think making it easier to find the monogram for any object quickly is a more general solution to this problem. T3725 discusses that from a @username viewpoint specifically, but I think we've also discussed a more general-purpose "object selector" button in Remarkup which lets you search for objects and embeds references for you. I'd rather make it easy to find any object than make it easy to refer to a specific, tiny number of objects which users have manually named.

The "mailing list" and "other pages" use cases aren't particularly compelling to me. I think the canonical identifier for object should be their monogram; it's bad if you're looking for references to T1049 on a mailing list and have to search for both T1049 and {Tharbormaser} and whatever other aliases users might have made. It's less obvious to a new user what to do with {Tharbormaster} on a mailing list than T1049, too. And, in this case, the rebindability of aliases is mostly bad/undesirable.

Overall, I'm mostly not sure this is a very good solution or that the problem it's solving is a very real problem.

But I don't really see any use cases for this, either.

A really weak use case is something like: some day far in the future, your build system uploads binaries into Phragment and automated systems know which release to download by resolving %duckadventure.releases.latest to a Phragment artifact. It's possible there are enough weak use cases like this scattered around various applications that this capability could make sense eventually, although perhaps primarily for non-human consumers.

At a minimum, I'd like to exhaust the general-purpose attacks on the larger problem (making it easier to find references to any object) and conclude that the task is impossible to accomplish before pursuing this.

Well, this feature does celebrate all that is awesome about Phabricator, "the glue". I'm all for more glue in the projects.

FWIW, rebindablity is not required for my usecase, although I could see usecases for it.

Yeah, it's nice in a gluey sort of way, I just don't see many gluey use cases for it.

If we implemented this feature without rebinding I suspect it would take about 5 seconds for someone to complain that they misspelled an alias, bound an alias to the wrong thing, someone stole the alias they really wanted to use, etc. The lifetime support burden of this feature without rebinding is far higher than the lifetime support burden with rebinding.

As a side note, the task numbers T1049 and T2015 are permanently etched into my brain.

As evident by @hach-que example - @epriestley is right that humans actually using task get task numbers etched deep into brain tissue. Most issue tracking systems then rely on either humans with good memory or good search features :-) I still can remember redmine taks numbers from years ago...

Thus I believe that aliases for object is great, but it would be mainly useful for non-human interaction... And it would have to be dynamic then, like for example - reffering to newest commit in repo as rP#HEAD and it would link to newest commit in repo. Then it would be grat for human interaction too :)

Another possible attack on this is Phurl (T6049), a planned URL shortener application, which has the U monogram. We'll probably support named URLs (e.g., https://your.install.com/u/corp can be a named short URL which takes you to the corporate site or whatever) and we could reasonably let Phurl URLs also resolve into objects (i.e., store "the object D123" instead of "the URL http://x.y/z"). Maybe named short URLs end up with a monogram like U/corp (generically, they'd be U/8anf1X for randomly-assigned short URLs) and perhaps that covers things.

I think named phurls would almost fully solve this use case.

It would fully solve the use case if I could put a phurl, into say, the "edit blocking tasks" box and have it resolve to the right task.