If users don't add a project, it is probably because they don't know to which project they should file their task. If you don't allow them to file the task without a project, they might try harder, or they might just file it wherever -- or go away without leaving any feedback.

At least in the case of Wikimedia, I'm looking forward to see those tasks landing without a project, a feature that I consider an improvement over Bugzilla, where users are forced to set one product-component and only one. If for some reason it is not convenient to triage these orphan tasks, we might just create a "Need triage" project, tagging these tasks automatically with Herald.

I'm sure there might be others, but Phabricator is the first task tracking system I use that doesn't enforce a top-level classification of tasks into "components" (e.g. iOS, Web, Backend...), which would be the equivalent of requesting tasks to be at least in one project. I would also expects most orgs to only use task tracking software internally (excluding customer support software like Zendesk), which means people are familiar with the names of the common projects.

It's reasonable to request some minimum effort on the part of the task creator: write a proper title, describe clearly what the issue is in the description and send it to the correct top-level project, so it can be routed faster. You wouldn't expect them to set priority, sub-projects, milestone or assignee and that's fine.

If your Phabricator is accepting tasks from the public or users outside the org where it is used, then it might make sense to not prompt for any project.

In our case we are thinking of fixing this issue by adding a custom field to tasks that lists the top-level projects we have (iOS, Web, Backend...) as a popup, along with writing a custom event listener that would enforce the selected top-level project to be always set accordingly in the Projects fields on task save or edit.

I so hated that feature of Radar, haha. It's decent if someone takes the time to maintain the ontology, but the 'bug wrangler' type person will always be better at this task than the layman. I'm sure this is supported with Events, but I'm not technical enough to give you specific instructions, but @epriestley might have a good guide sitting somewhere.

In general we're not super hot on adding (and supporting) config options if we can avoid it. Events are more powerful anyways and keep the product simple for most installs. Obviously if something keeps coming up via the support channels, we'll consider adding such things.

@chad I certainly don't remember it being a problem at Apple but maybe it was the case in some groups. Actually, I would say that's a great example where you certainly need to enforce a top-level component at the bug creator level: you can't imagine bug going to "Apple" and have some bug router person at this scale ;) If one is reporting a bug on TextEdit, you set the component to TextEdit. Same for technologies like WebKit. Anyone can figure this out. Then regarding the subcomponents (WebKit / Rendering), you wouldn't expect the bug reporter to know about it or even do it.

I didn't know what to do in Radar, I just worked in Design (Marketing) at the time so it was a pretty foreign tool. I would file tasks to Safari [New Issues] or something similar and hope they made it somewhere. At least with Events you can develop your own trickery - like requiring Eng/PM provide a Project, but not others, for example.

Yes events are a workaround for part of the problem (set a default assignee per project), but then they become a problem when now you have to enforce conventions when people create projects so they remember to create Herald rules or tasks are lost. In any case, the primary problem is the possibility for tasks to be created / edited without a project. Now you need someone who's (yes part-time, but still) job is just to watch and route these. What if this person is very busy or on vacation, etc...

In your case at Apple it still worked since you were able to file tickets against Safari: at least they landed in the right world and weren't in limbo :)

re: events - Chad was talking about implement something via this https://secure.phabricator.com/book/phabricator/article/events/ This should let you build whatever you want, and if not we should extend / enhance it to make that work.

To me, the question boils down to whether or not the people who can file bugs are employees or some Internet-wide rabble that cannot be influenced. If the former, employees really should be trainable, and to some degree you're at least solving explaining the project hierarchy, how to use Maniphest generally, etc. Further, you can hold employees accountable to being good at stuff...! If the latter, a systematic, tool-based solution is required to enforce rules, and note that we don't think Maniphest should be tailored to that use case. (Rather, we think another application yet-to-be-built should handle "incoming stuff from the rabble" like bugs, customer support tickets, etc.)

I think something lacking here which would be nice is if Herald could assign tasks to the task creator. This would then let you create a Herald "global task validation rule" that could re-assign to the creator. There might be other holes in Herald to make this work nicely.

As a process point, what is the cost of not addressing bugs ever that are improperly filed? (Or in other words, rather than have some looking through the poorly-filed bug pile, why not ignore them?) I'd guess that important bugs will be filed again, and otherwise employees who improperly file bugs will be quickly corrected via management.

After T5016, you could also add a mandatory "Component" dropdown field, then write Herald rules like "When task is in component X, add project X".

I think something lacking here which would be nice is if Herald could assign tasks to the task creator. This would then let you create a Herald "global task validation rule" that could re-assign to the creator.

I don't understand how this would help fix this situation?

As a process point, what is the cost of not addressing bugs ever that are improperly filed? (Or in other words, rather than have some looking through the poorly-filed bug pile, why not ignore them?) I'd guess that important bugs will be filed again, and otherwise employees who improperly file bugs will be quickly corrected via management.

I'm going to have to strongly disagree with this point of view, especially in the context of a small org. It's a slippery slope. If you want to track things properly then you do it all the way.

I also agree that it would be ideal to enforce such constraints using Herald but it cannot be done today since a Herald rule can't pre-validate a task being created or edited and reject the operation. The alternate approach would be the mandatory "Component" dropdown field mentioned by @epriestley combined with T5016 but who knows where this will land? ;)

The Herald rule would help because if the task wasn't filed properly you can then automagically re-assign it to the person who filed it. They can create at will but the task just gets re-assigned to them if they did it wrong so they can "try again".

I understand now. That's a good idea. Is there a task already on this?

I filed T5162 for the Herald thing.

Also, see T4778 for more "when will a thing get built?" insight.