In Phabricator, all projects are in fact tags and all tags are in fact projects. The visual distinction doesn't come from Phabricator, but from our conventions. Technically, the only difference between a regular project and a tag is an icon and a background color. Phabricator knows no more.
Declining, because changing the current behavior would be a big big task that should be discussed and eventually done upstream.
The current behavior is actually fine. People can join and watch them, and if someone wants to help working on tasks related to a tag, they can setup the workboard and treat it as an actual project.
I'm not talking about dramatically changing Phabricator's implementation here. Sorry if that was unclear.
In this task, I'm talking about the list that appears in the basic task view above. Where it says "Projects" above, it should only list projects. Below that, it should have a separate field for "Tags".
Clearly Phabricator is already aware of the difference between a project and a tag by giving a different icon and background color, so why not expose that distinction rather than incorrectly calling (for example) "easy" a project?
I don't think modifying the basic task view to add an additional label will require a Herculean effort. :-)
(I'd also caution against rash actions in Phabricator, just as we did in Bugzilla. It's important to give ideas time to percolate or to be discussed and considered before simply rejecting them because of some silly Phabricator mantra.)
No, Phabricator just does what we users do manually when editing a project. Now "easy" is yellow and shows the icon of a tag. Alright, go here and change it for something else. Phabricator just renders what you define there. We cannot define a separate category of projects based on the color and the icon users select for their projects at a certain point of time.
Instead, I recommend you to embrace the Phabricator mantra: projects are tags, tags are projects. :)
Aha. Thanks for the link.
Maybe changing the label to "Metadata" or "Tags" instead of "Projects" would be a simpler solution. The current term seems wrong to me, but perhaps I just need time to accept it. :-)
I have seen several comments from upstream maintainers saying that "Projects" should have been called "Tags" since the very beginning. While I agree with this as an advanced user, I can also see why that rename would cause other kinds of trouble, perhaps even affecting reputation adoption ("Phabricator? Do you mean that piece of software where you can't even have a project to organize task?")
Back to your request, the distinction between tags and projects would be purely representational in the UI, and I'm not sure whether this is worth the effort or even a good cause ti pursue. The fact is that Phabricator offers exactly the same to all projects/tags, regardless of the icon and color of choice. It is also interesting to communicate that any tag out there is welcoming a potential group of contributors willing to plan their work around that focus area. For instance, in the case of "easy", we could have different workboard columns for tasks that have been verified as easy (as opposed to i.e. Tim Starling saying that rewriting that API method can be done in a couple of hours), a selection of candidates for "Bug of the Week"...
Let me decline this, setting priority to Needs Volunteer. If someone has an idea to work on this, feel free to reopen and propose.
It would perhaps help if https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Type_of_project didn't produce the mistaken impression that "project, team, sprint, release, tag, private" constitutes a partition, while in fact "team, sprint, release, tag, private" are a partition* of a non-trivial subset of the set "projects".
An easy solution would be to rename the "project" type (the default) to "component", a terminology users will be familiar with. Then "component, team, sprint, release, tag, private" should be a partition of "project" and we should avoid confusion on what "project" means, because it will be used with one meaning only.
(*) Or at least I hope so. Can they overlap?