Redmine

Ok, i dove into the subject and find i'm not alone.

So i'll provide some history:

Subtasking was #443 and got implemented as r3573. There is a somewhat lenghty discussion on the issue at #5490.

Reading through this stuff I find myself supporting the opinion that current behavior is counterintuitive and kind of breaks subtasking.

Maybe one could think about variants of how subtasks will be linked with their parent tasks influencing how information rolls up or not. But I feel roll-up is wanting too much and thus results in conflicts with too many usage scenarios. Especially if rolled-up information ends up modifing the parent task, roll-up is bad. From my point of view controlling a task from subtasks is a project-controlling-no-go and must not be done without approval of the project manager.

I advocate that:
A) Default behavior should be to keep fields on different issues intact and available at any time.
B) Roll-up of information is helpful as additional information to be displayed in parent tasks.
C) Resetting fields in parent tasks based on values in subtasks might be helpful as an action to be triggered from the parent task.
D) It would also be helpful to have reports comparing rolled-up information with the respective fields of the parent task.

A should be trivial, B should be fairly obvious to implement. I expect C to require implementation with various variants, options or local extensions to mach the workflow of the company or team using redmine. D might suggest some kind of best practices of project controlling and appeal to a more general audience if done right.

Best regards and thanks for comments!

.

I don't now if it's the same, but I posted it as issue here

Has anyone come up with a way to get around the "adding a sub-task removes the parent task's estimate" issue? I understand the current semantics and agree it's not totally obvious that the current behavior should be eliminated, but I would like to have the option that a parent task's estimate remains whether or not there is a sub-task on the issue. We're really struggling with the current behavior.

Our use case is fairly straight forward:

• A task is created with an estimate and assigned to a developer.
• The developer works on the task and discovers they need a sub-task to
  • (a) help them manage their work, or
  • (b) to assign to another developer
• The creation of the sub-task is independent of the original estimate - it should leave it alone

With the current behavior, the estimate is lost on creation of the sub-task. I've not found any easy way to workaround that - even ugly hacks like, creating a shared parent before creating the sub-task don't really work (because the second task is INTENDED to be a sub-task of the first).

Has anyone else dealt with this use case in Redmine and come up with a satisfactory solution?

And now I see that 14 days ago, revision r14272 was made on task #16092 that appears to address the issue. Cool! Looking forward to seeing when that comes - even more to see if we can apply it early.

To complete: r14269, r14270 for issue #5490 and r14273 for issue #17550 were recently committed too. This is a real progress compared to the strictly derived defaults currently.
OTOH, I haven't tested this in-depth enough yet to say that there're no more side-effects anymore which can be considered undesired (eg. my otherwise unrelated, old issue #6687).

Hope this helps...