Who's happy with current subtask/dates handling
Added by Eric Voisard almost 12 years ago
I'm suprised that there are not more reactions to actual task/subtask start/due dates handling.
Subtasks start/end dates controlling and changing start/end dates of main tasks is really odd to me. I don't understand the underlying logics and it doesn't fit at all with how we work on our projects.
Say for example that we assign to a developer some main task called "Coding of the new RS-232 interface" that's two weeks long. If at some moment during the development, we create a subtask called "Make a null modem cable for tests" that only takes one day (say we assign it to another person), then the main task "Coding of the new RS-232 interface" gets its start/due dates shortened to one day...
IMHO, this is an absolute nonsense!
Current implementation is rigid and restrictive and it kills this long awaited feature. In fact, subtasks are not usable at all in our case. And I'm wondering who can use them and how they do...
There is an issue (#5490) that's been opened about one year ago, and several others which are closely related.
Subtasking should be made more flexible. There should be options like Andreas proposes in defect #5490 ...
RE: Who's happy with current subtask/dates handling - Added by Hans Bangkok almost 12 years ago
Well, I was aware of how RM handled this before I started implementing them, so my use is in line with the devs' intentions and it works well for me.
I think of parent issues as "empty containers", hierarchy-indicating placeholders designed to group related tasks together to help me organize my query/views. This is true for any items with subs - all "real content" (in the sense of items representing work) are bottom-level "leaves" in the hierarchy.
The parent issues' automatic updating based on changes to their subs (not just dates but priority, estimated time length) is very helpful - otherwise you'd need to remember to go back and edit the containers manually (i.e. they'd quickly get out of sync).
I also make sure that no one puts important notes into the "leaf" action items, as these in effect disappear when "done" - the parent containers of the action items also hold the ongoing commentary related to all their subs. Only when a containing parent gets flagged "done" as a whole do the associated notes then need to be extracted and summarized, and generally that's a manager's task.
Hope this helps. . .
RE: Who's happy with current subtask/dates handling - Added by Eric Voisard almost 12 years ago
I can understand this philosophy in some contexts, however I think people using Redmine manage their projects and their tasks in many other and legitimate ways than this one.
Usually, Redmine is open enough to offer ways to overcome intrinsic limitations, but in this case, Redmine itself imposes a limitation.
Imho, this limitation is as arguable as the answer to "what's the best management method" (which should be "it depends" (or "42" maybe ;)). Whether adhering to this subtasking philosophy or not should be an user choice...
RE: Who's happy with current subtask/dates handling - Added by Òscar Casajuana over 9 years ago
Sorry for reviving the post, but this behavior threw me off a lot.
Couldn't this be an option? Something like "force parents to calculate priority, time and date from children".
RE: Who's happy with current subtask/dates handling - Added by Jan S almost 9 years ago
I'd also like to have a toggle for this behaviour as an option.
RE: Who's happy with current subtask/dates handling - Added by Anonymous almost 9 years ago
This behaviour can't be the default, it can be useful if you can control it from the parent or by task type.
RE: Who's happy with current subtask/dates handling - Added by WDS D about 8 years ago
I'm not happy with this implementation and I agree that this behavior should be an option. I can totally understand that it works for many but for others, it is not suitable at all !
RE: Who's happy with current subtask/dates handling - Added by Lucile Quirion about 8 years ago
Would you like to test the patch which address this issue ? #5490-82
You can apply it with the command
git am some.patch