This was actually identified as a feature, compared to Bugzilla's enforcement to select one-and-only-one product/component in order to publish a report. It allows users not knowing where to file a report to leave it empty.

Maybe but judging all the e-mails I've received in the short time I've been on Phabricator about tasks without projects at least some kind of warning e.g. "You are creating a task without a project is that okay?" would be a good idea.

and the canned message I get for this should probably be reworded for newcomers as it seems rather negative...
"Please associate at least one project https://phabricator.wikimedia.org/project/query/active/ with this task, otherwise nobody can find this task when searching in the corresponding project(s). Thanks."

The interface for adding projects during task creation is sub-par, If we want to force this, we need to fix the UI first.

In my view, We should just stalled/decline this until we come up with a use case for forcing their addition.

Declining works for me, as argumented above.

I really think we should do this - creating tasks with no projects is inevitably foisting work on someone else's queue and the worst you could do by adding some is foisting that work on a different someone else's queue.

In T95962#11192528, @Pppery wrote:

I really think we should do this - creating tasks with no projects is inevitably foisting work on someone else's queue and the worst you could do by adding some is foisting that work on a different someone else's queue.

TBH, I think I disagree here. In my experience, if I look at the "new tasks" feed & see a task without any specified projects, I can easily see that it needs triaging into its specific codebase(s); whereas if I see a task with a codebase tag attached to it, it's not immediately obvious (without clicking into & reading through the task) whether it's actually tagged against the correct codebase or not. It might just be me who thinks this; but to be honest, in general I think I'd rather that people leave the tags blank if they're not sure what tags to add, than to add tags that they're not really sure about.

[…] the worst you could do by adding some is foisting that work on a different someone else's queue.

I respectfully disagree that this is the worst that could happen - this could also result in tasks being inadvertently left in (incorrectly-tagged) projects that effectively function as blackhole routes (due to e.g. a codebase being sporadically/no longer actively maintained, a project tag not being regularly checked, etc.). This could mean that tasks which might otherwise be worked on might just end up sitting in their incorrect projects, until someone happens to come across them by chance and retag them as appropriate (if that happens).

A partially-related example I'm aware of in the past is T376362, which was initially triaged into Expiring-Watchlist-Items; where it sat for 5 months before it was retriaged into Wikipedia-Android-App-Backlog (and was then worked on by the Android app devs within the month). I'm worried that forcing task filers to include a project tag when they're not sure of which one to use would result in a number of additional situations similar to what originally happened there before it was retagged.

I think it's a good thing that users are able to create tickets _without_ having to know all tags and the internal team structures.

The actual problem we have is that users who are not regular Phabricator users often hesitate to create tickets at all.

A common theme there is "I wasn't sure if it's worth a ticket / if it's ok to create a ticket for this / did not know who to tag / did not know how to fill it out".

This leads to people pinging others in realtime chats for things that should be tickets in the interest of everyone.

To mitigate this I often encourage users by telling them things like ~ "don't worry about the right tags, it doesn't have to be perfect, others more experienced will triage it and take care of it later" and "just treat it like an email".

To me this is just normal "wiki-style" collaboration.

Anything that encourages people to create tickets _at all_ that reduces the real-time chatter is a good thing. Adding more requirements for what is an acceptable task is not a good thing imho.

The role of someone looking at incoming tickets and triaging them is needed regardless.. it can't be dropped. So the experienced users who know the organization, the teams and tags should take care of that.

After ten years I still have the opinion that this task should remain "declined"