Thanks for your clear response!

I understand it's a slippery slope, and if not thought out well would rapidly lead to an unmanageable state.

Regarding workflow/checklist app:
Some of these tasks are discussed, like a "News module" taks where functionality is debated.
Also, there is not really a full-on chronology. Some tasks are dependent on others (and thus marked as depending task).

The example of a use case you requested:
We have one project for each website/app/... we create.
Sidenote: There are other projects, functioning like tags (Easy, Delight, ...). Much like you do here.

So, when starting a new website, there are a lot of tasks recurring each and every time. Some examples:

• Set up hosting
• Register domain name
• Collect resources
• Check legacy browsers
• Redirect old indexed pages
• Set up analytics
• ...

Most of these tasks have more specific subtasks.

I'm talking about 50+ recurring tasks here.
The template-parameter solution mentioned in T3320 would be a solution, albeit a cumbersome one.

Just popped in my head:
A real quick 'n dirty way to accomplish this would be to have one text area for mass-creating tasks, where you could type/paste a simple tree structure, like

• Task 1
  • Task 1a
    • Task 1a sub
    • ...
  • Task 1b
  • ...
• Task 2
• Task 3
• Task 4
• ...

A bit like some CMS'es have to mass-create a page-structure.
It provides lots of flexibility, is simple and wouldnt put things "in a bas state".
This approach, of course has its shortcomings, like not being able to assign priority, user while mass-creating etc.

PS. Don't shoot me for coming up with this hack. I know this is by far the most elegant way to handle this situation :)

I actually think that hack is pretty reasonable -- it's probably not something we'd want to put in the upstream, but it could likely be built with an extension fairly simply after the next API update (you could create the tasks via the API today, but the API doesn't currently expose features for linking them to each other -- see T5873). I think it does a pretty good job of avoiding the problematic / accidental outcomes where a thousand duplicate tasks get created and no one realizes until it's already done.

If you have common cases like "new website", you could even have the template be like:

Site Name: [example.com______]
Template for Tasks: 
  - Set up hosting for {$sitename}
  - Register {$sitename} domain name
  - Collect {$sitename} resources

...etc., and then the extension could be smart enough to replace the variable in the template when it created the tasks, so you ended up with "Register x.com", "Register y.com" tasks instead of 100 copies of "register domain". And I could imagine letting the parser recognize @username to assign the tasks, etc.

(We had one similar idea kicking around a while ago which was "provide a way to quickly create a bunch of tasks if you're in a meeting", but I think that got mostly solved with Workboards and we'd probably want it to be a little more structured than a big text field.)

Given the use cases we've heard from other users so far, this feels a little too special-purpose to actually upstream, but I'll keep an ear out for other things which this might be a good fit for. I think it would be easy (a couple hours of work) to develop an in-house extension version of it after the API next gets updated. That API update is on our short-ish term roadmap, but it's behind a lot of stuff (we're focused heavily on launching our SAAS product right now, so most major product development is waiting on that) and I expect it's at least a month away and probably further out than that.

Great, works for me.
Will keep an eye out for the updated API in the coming months!

This is an essential feature for organizations running many, similarly structured projects. For us, each project is essentially a workflow of a predefined series of tasks that need to be tracked, assigned, and discussed individually for each project. Of course, each project will grow its own, custom additional tasks, too.

Having to create these tasks manually for each project is a deal-breaker. Batch-creating them using a text area will push the maintenance of these tasks elsewhere. I don't really see a better alternative than simply creating a "template project" that can be instantiated or copied to create a new project. However, any other solution is welcome!

To clarify, this needs not be specific to tasks. It'd be awesome if the project menu can also be templated.

I see there is some similarity, but some important differences in the use cases:

• We are interested in splitting a specific task, crafting the title and description in particular, manually (in fact, with quite a lot of care), whereas here the focus is on creating generic tasks, or templated tasks
• We would not want subtasks to be copied, I don't think
• We need to be able to edit the original task at the same time as creating the new ones, whereas there is no aspect of that in this use case

Looking at the template etc. parameters (T3320), they cover a good chunk of what we need, so if it could be exposed in the GUI via a "Clone task" function or something, so we could apply any particular task of our choice as a template, it would make significant progress in solving our use case. It wouldn't deal with subtasks, so that difference in use case wouldn't matter. The main deficiency for our use case would be the lack of ability to concurrently edit the original task.

How much time per day do you expect this feature to save you?

All of your use cases fall into this task, I believe. That being "I want a new task based on x, y, or z" We want to group similar feature requests together for planning reasons, so multiple root problems can be solved by a common, thought-out framework. I can't guess what the UI would look like, or if we'd offer anything else like you're mentioning. I appreciate the detail on the original task, but in general we're not likely to be able to get more into a discussion on a task thats several years away at best.

Though this task also talks about Project Templates so maybe we should have two tasks.

I don't have a problem grouping the use cases together, and it makes a lot of sense to solve as many use cases as possible per feature. I just wanted to point out the differences so that when this task progresses, it can progress with the different use cases in mind. At a first glance, I didn't think the use cases were very similar at all, as this is a lot about creating a bunch of tasks by template (or from a template project), which is a bulk action, really, whereas really our use case is about task micromanagement. However, on further consideration, there is significant overlap, especially from what T3320 brings to the table.

It's hard to say how much time this would save, because this happens most frequently in our content development, and our team size and allocation varies day-to-day. The saving may be modest, at something like 10 minutes a day. I think the greater benefit would probably be in removing the hurdles to doing this; we'd benefit from having our tasks better organised, because people would actually be more inclined to split them when they should. This would indirectly save a lot of time because tasks wouldn't be closed which are only half done and then have bugs raised which are tracked back to the task and then backups are checked to see if something went wrong with deployment, and then the proper status of the task is ascertained, etc., etc..

I personally would keep the tasks separate, as I think the concurrent editing requirement is the harder problem to solve. The templating aspect is already mostly done by subtasks and T3320, and adding a slightly modified clone task function would not be hard, I imagine. Much harder is allowing you to really split a task by being able to move material between the two tasks (original and new) on a single page or solving that difficulty some other way.

It's fine if discussion of this needs to wait. This isn't a huge problem, and even if it were, it's not up to us to set your priorities. But it's a problem we're encountering, and we'd benefit from solving it at some stage if possible.

I think https://secure.phabricator.com/book/phabricator/article/events/#ui-did-render-actions still works, that you can build a "Clone Task" action on the side of your Maniphest links and have it use that task as a templateID. Might be worth fiddling with locally.

Thanks for the pointer. I wondered if there was something like that I could hook into.

Of course, it would be more valuable if the API were more stable, and ideally
something would eventually be implemented upstream that addresses our use case.

Events stuff isn't on any roadmap, so it also could be years before it was modified.