Forcing a Triage also enables people to add dependencies and subtasks, otherwise they might forget that, because one can't add any dependencies while creating a task.

I would still like All users to be able to edit/view the priorities of tasks, but I just want to move assigning priorities to a time after the task is created for the reasons I mentioned above. Its like a cool-down period.

I use the same trick when I (think I) need to buy something big. It goes into a list. I prioritize it only after some time has passed and if after a few weeks or months I still feel like its important, then I buy it as opposed to buying the damn thing the first moment I think I need it. Its the same with tasks.

+ @epriestley, @chad in case they feel differently

The original was

Use case: Every new task tends to be marked High in my projects by some people, because new tasks always seem more important than anything else.

That is very much a social problem that won't be solved by this feature request, so much as make it more inconvenient (ostensibly, just adding the steps of click to edit, change priority, click to save). I don't like to make things more inconvenient for people as a general rule, particularly when their should be a social fix, i.e. tell "some people" not to re-prioritize tasks and if its really a problem exert organizational pressure to stop the shenanigans.

I mentioned T390 because the next bit

Forcing users to prioritize tasks later would make them be a bit more realistic.

Makes sense to me on a per project basis for certain types of projects. For example, in a "sprint" project where by design folks are not supposed to have their current plates churned during a sprint, non project members probably shouldn't be able to throw in high pri tasks willy nilly. I think sprint projects should thus have configuration that only allows project members to change the priority of tasks in that project, and then the configuration I mentioned in my last comment can drive the rest.

I basically dont like the last bit

This feature would only apply to completely new tasks, not tasks that are created based on other tasks

As that seems confusing in the general case, although perhaps applicable to your specific workflows. Further, if "some people" are clever, all they have to do is create a task based on another task, edit it a bunch, and bam, you're still getting high pri tasks.

I'm 100% with @btrahan here. You can sort of use event handlers to provide extremely special-cased workflow rules like this, but will have better luck sometime after T2217 is finished.

For me I cannot solve this socially as the people in question change all the time as I take on new clients. Its more time-costly (for me) to teach the world, rather than make the workflow a bit byreocratic.

If Phabricator is used in company X as an inhouse solution to manage inhouse projects with the same people all the time, then yes: it would be better to teach them proper prioritization.

Mind you it would still be an optional config setting for people who think like me.

@btrahan I changed the last bit you mentioned, because your argument made sense :)