We use Phabricator for task management for the development of a educational software product which involves both application code and content. The content is organised into lessons, and we have thousands of these. They are identified by codes which are not very human-readable, such as 9M1AB2 (for historical reasons, but changing it would be a huge undertaking).

It occurs frequently that we want to split tasks. Here are some scenarios when this happens:

• A similar change may be required to half a dozen lessons or so. We create a task for that change, and copy and paste in all the lesson identifiers. Upon review, some lessons are ready to progress to deployment, and others need further work. At this point, we want to split the task. Generally we will repurpose the existing task for the lessons that are ready to progress, and create a new one for those that require further work, referencing the old one for the history.
• Similarly in software development, sometimes we find we can and want to meet some of the acceptance criteria for a feature, following it through to deployment, but others require more work. We will generally do the same thing as above.
• Other content tasks can require changes to many lessons. If a task affects, say, 120 lessons, once we have identified those lessons (which is often the first part of the task), we then want to batch them up into manageable units of work. Generally we do this by creating subtasks, peeling the lessons off in batches of 10 or so, which can reasonably be actioned within a day or two, reviewed and deployed (though sometimes requiring further splitting). So this scenario is a bit different to the ones above, because we are creating subtasks, not just 'sibling' tasks.

Typically, this requires us to do something like this:

• Navigate to the task to be split (this can't be avoided!)
• Open a task or subtask creation form in a new tab
• Put the original task into edit mode
• Unless it's a subtask, where the data is prefilled, copy the projects, subscribers, assignee and priority (usually); this can involve quite a bit of switching between tabs
• Cut and paste bits of the Description and Acceptance Criteria (a custom remarkup field we have); note that we often cut here, so the original task is edited as well as the new task
• Submit the new task
• Move the new task on the workboard, often to the same place the original task was
• Make explicit mention of the new task, now it has a T-number, in the original task Description, and submit the changes (or sometimes we would make a comment instead of mentioning the new task in the Description)

It would be great if this workflow could be simplified. Some ideas I had:

• Add a 'Clone task' function near 'Create subtask' which copies the task's existing fields.
• Add some mechanism to allow easy migration of data between the original and new tasks. For example:
  • Add some button to the remarkup toolbar when creating a clone or subtask allowing you to access and edit the remarkup of the original task. When you submit, both tasks would be updated.
  • Some kind of 'side by side' view when creating a clone or subtask, showing original and new tasks. Again, when you submit, both tasks would be updated.
• Mitigate the need to reference the new task:
  • If the new task were automatically referenced in a transaction in the original task (e.g. "ben cloned this task to create Tyyy" and the new task could have "ben created this task by cloning Txxx") perhaps explicit mention of the new task would not be necessary.
  • You could have some magic replacement text while editing the original task and creating the new one (if we have a dual purpose form) such as "T??" (T followed by more than one question mark) which would automatically be replaced by the new task's number when you submit
  • If a side-by-side view is adopted, allow the sides to be submitted independently, so you could save/create the new task, at which point the fields would be locked, but the new task number would appear so you could copy it into the original task and then submit it, too.
• Allow the workboard column to be specified while creating tasks, and/or when tasks are created as subtasks or clones, if they have any projects in common with the original task, put them in the same workboard columns, too.

This would avoid the necessity of tab-switching and minimise the copying and extra administration. That would make our task management easier, which would mean we could focus more on actually completing the tasks, and there would also be less hesitation from users to split tasks when they need to (which is currently a challenge for us; some tasks end up in a bit of a confused state; they are half done and should have been split, but haven't been as it's a bit of a daunting job to do it).