Community
Participate
Working Groups
Environment: STS 2.3.3.M1 (Mylyn 3.4) Repro steps: 1) Create a local issue A 2) Create a subtask B for that issue 3) Select 'Categorized' within the Task List view 4) Check 'Group Subtasks' 5) Notice that subtask B is grouped under A as expected 6) Schedule A and B for 'This Week' 6) Select 'Scheduled' within the Task List view 7) Notice that A and B are not grouped as expected, but rather appear as top-level issues This was surprising for me. Subtask grouping is an important feature, and the Scheduled view is probably even more important, but they fall apart when mixed. It's not uncommon to have an issue with many subtasks; if they're all scheduled for this week, the effect can be overwhelming, especially when dealing with several tasks each with their own subtasks.
An important feature of the scheduled presentation is that it is never supposed to show duplicates. For bug trackers such as Bugzilla that support arbitrary linking of tasks showing relationships can break that expectation. That said for bug trackers that have a strict subtask hierarchy like Rally I believe the scheduled presentation will actually show subtasks under the parent task. I agree that there are cases when it would be useful to support grouping in the scheduled presentation. I'll ad this task to bug 248377 so we consider this when we look at a redesign of the content provider.
*** Bug 248988 has been marked as a duplicate of this bug. ***
(In reply to comment #1) I just want to add that this problem (distinguishing subtasks in the Scheduled view) applies to Local Tasks, which are all that I'm using, so I hope this can be straightened out despite how the real bug trackers mentioned in your comment work.
Let's discuss for 3.6.
Steffen: Where are we at on this front? I really miss this feature from the 1 day that I had it. Tentatively putting on for 3.7.
There is a still conceptual problems that we have to work out before we can enable this: * It is unclear in what order to show tasks, e.g. if a subtask is scheduled before its parent task * Drag and drop becomes complicated, e.g. if a parent task is moved, does that reschedule subtasks as well * If we force hierarchies this would lead to duplicates These are just from the top of my head but there is probably more that I'm missing.
(In reply to comment #6) > There is a still conceptual problems that we have to work out before we can > enable this: Good points. I think we need to lean to simplicity here to make it feel more like typical tree views in Eclipse, even though we do have some different display algorithms to deal with, like guranteed visibility. > * It is unclear in what order to show tasks, e.g. if a subtask is scheduled > before its parent task This seems like a pretty standard sorting problem. I think that it has to do the simpler thing of sorting each level independently, as we see with sorters in other hierarchical views in Eclipse. In other words, scheduling dates of subtasks do not affect sorting of the parent. Subtasks then get sorted by their date within their parent. > * Drag and drop becomes complicated, e.g. if a parent task is moved, does that > reschedule subtasks as well I think it should be similar to the above. Only the parent task gets it's scheduled date set. > * If we force hierarchies this would lead to duplicates This is where things get more complex. What's a good example scenario here, two tasks are scheduled for this week, and two of their children are scheduled for today?
Steffen: Any comments on this? I still see this as a significant impediment to the Scheduled presentation for use on repositories that make strong use of hierarchy (eg, anything involving Agile planning). Also, I think getting the design right will help us refine the Task List design, since it will determine whether the Scheduled presentation supports hierarchical task schemas.
Steffen: Any thoughts on this?
(In reply to comment #7) > > * It is unclear in what order to show tasks, e.g. if a subtask is scheduled > > before its parent task > > This seems like a pretty standard sorting problem. I think that it has to do > the simpler thing of sorting each level independently, as we see with sorters in > other hierarchical views in Eclipse. In other words, scheduling dates of > subtasks do not affect sorting of the parent. Subtasks then get sorted by their > date within their parent. Would you expect nesting to work only within the bucket or should subtasks always pull in their parent task regardless of its scheduling status? Should all subtasks of a scheduled task always show or just the ones that are scheduled? My sense is that we should always enforce that everything shown under a bucket matches its scope, e.g. all tasks regardless of their level in the hierarchy should be scheduled for Today. > > * Drag and drop becomes complicated, e.g. if a parent task is moved, does > that > > reschedule subtasks as well > > I think it should be similar to the above. Only the parent task gets it's > scheduled date set. Then subtasks remain in the previous bucket or do they move as well? What scopes visibility of subtasks? > > * If we force hierarchies this would lead to duplicates > > This is where things get more complex. What's a good example scenario here, two > tasks are scheduled for this week, and two of their children are scheduled for > today? It depends on the criteria for showing subtasks or parent tasks. If we enforce that all tasks under a bucket match its scope duplicates become a non-issue.
Steffen: Can we consider this for the 3.7 plan/backlog?
Yes, it's marked as plan and hence I consider this item to be on the release backlog.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
