Community
Participate
Working Groups
Each query contains a flat list of tasks; I suggest to allow user to group them by some filed: for example I have a list of tasks assigned to me; I'd like to group them by 'milestone' property. This functionality exists in Deskzilla (http://almworks.com/deskzilla/overview.html) and I desperately miss it (((
We've are planning to add the ability for connectors to contribute alternate content providers and filters to the task list for Mylar 2.0. Once these two capabilities have been added we will be able to support various sorting/grouping such as what you suggest.
While they are already on the 2.0 plan, please consider voting for one or both of the following: * User-defined nesting: bug 153753 * Allowing custom hierarchies to be added to the Task List (e.g. product/component/milestone): bug 170681 *** This bug has been marked as a duplicate of bug 170681 ***
Hmm. I would say that this issue is probably different then contributed models. For example, Mylar could allow to group by any of the shown columns without special model support. But that would require to resolve bug 126788 first.
I think this bug is not a dupe, but rather a sub-task of the other bug. This addresses one possible model described there. That issue describes the need to have pluggable models; this issue describes one such model. Compare it to a new api (other issue) and one impl (this issue). But i'm fine with this being the dupe, i'll watch the other issue. (I don't get why this is marked resolved, as the original bug isn't)
Agreed that this is best marked as a task that's dependent on bug 170681 since that bug is so broad. I'll tentatively set for 3.0, and we can use bug 170681 to discuss UI design and implementation strategies. Regarding it having been resolved, Bugzilla automatically sets duplicate bugs as resolved.
*** Bug 195710 has been marked as a duplicate of this bug. ***
Some connectors may want to allow to group query results in a repository-specific way: for example by assignee, by due date, by target component, target version or other connector-specific attributes. Such grouping don't really makes much sense at the global Task List level, because these properties can't be generalized, but they fit quite well for the individual queries.
Created attachment 73595 [details] generic groupby support for TaskListContentProvider I've tried to introduce new presentation mode for groupping, but it turns out that it make more sense to have generic support for groupping in TaskListContentProvider. This patch adds reuired functionality to the content provider, adds new "group by" menu to the Task List view (by owner, priority, kind, repo, sheduled and due date), code to save and restore grouping mode and restoring upon focusing activation.
Created attachment 73597 [details] mylyn/context/zip
Created attachment 73599 [details] example this is just one of supported grouping modes PS: btw, it doesn't seem like incoming decoration is rendered correctly on those group nodes.
Forgot to mention that as a side effect, Archive category can be grouped by repository, which is quite handy for cleaning up some garbage.
Eugene: could you consider splitting this into (1) a Sandbox patch that uses a presentation and into a separate (2) patch that just groups the archive by repository? As you know we need (2) asap and there is no additional UI complexity to work out there. (1) is tricker, we still don't support deeper nesting properly on all platforms due to custom draw problems, and as you know I want to tread extremely carefully with supporting more nesting. Also, note that TaskListContentProvider requires a rewrite.
Mik, I don't understand your comment about presentation. The patch I've proposed does exactly what original request is asking for. It does work across both existing presentations. Also it does not making nesting deeper... well, almost. It is the same as for subtasks without grouping, so subtasks go one level deeper when grouping is on. Also, this is quite simple patch that does not change internals of the content provider or the task list presentation. I think for such simplicity added value is very very hight. I finally been able to clean by Archive category and grouping by priority or by the owner is simply priceless (i.e. I immediately found few wrong assignments).
To clarify. The change for content provider is quite isolated. The only changed method is: public Object[] getChildren(Object parent) { return getFilteredChildrenFor(parent).toArray(); } and change look like this: public Object[] getChildren(Object parent) { List<AbstractTaskContainer> children = getFilteredChildrenFor(parent); *if ((parent instanceof AbstractRepositoryQuery || parent instanceof TaskArchive) && view.getGroupBy()!=GroupBy.None) { return getGroups((AbstractTaskContainer) parent, children).toArray(); } else if (parent instanceof TaskGroup) { return ((TaskGroup) parent).getChildren().toArray();* } else { return children.toArray(); } } private Collection<TaskGroup> getGroups(AbstractTaskContainer parent, List<AbstractTaskContainer> children) { TreeMap<String, TaskGroup> groups = new TreeMap<String, TaskGroup>(); for (AbstractTaskContainer container : children) { if(container instanceof AbstractTask) { AbstractTask task = (AbstractTask) container; String key = view.getGroupBy().getKey(task); if (key == null || key.length() == 0) { key = "<unknown>"; } TaskGroup group = groups.get(key); if (group == null) { group = new TaskGroup(parent.getHandleIdentifier(), key); groups.put(key, group); } group.internalAddChild(task); } } return groups.values(); } In result this stuff is working for both Categorized and Scheduled presentations. So, it doesn't seem like moving it into separate presentation would allow us to have same functionality without duplicating code.
I realize that this is a small fix with significant potential for value and waaay back we used to support this kind of category nesting/grouping, which we then realized complicated the UI tremendously and have avoided nested containers sine. Some of the reasoning is related to the accepted tradeffs between hierarchies (e.g. Microsoft Project) and monocline lists (e.g. modern Apple UIs) and leaning towards the latter (for some background as to why see literature such as: http://platypuswiki.sourceforge.net/whatis/inspirational/cooper.html ). I also added an entry on this to: http://wiki.eclipse.org/index.php?title=Mylyn_Focused_UI_Design&action=submit#Avoid_Hierarchies That said, I definitely do not want to slow down experimentation in this area and there are use cases where hierarchies are useful, which is why this item is scheduled for 3.0. However, this simple addition needs more UI design because it is so closely related to changes we are planning with bug 170681 and because it overlaps with query creation as discussed on the weekly call. We created Presentations for the purpose of experimentation, and this can easily be added to a presentation. To facilitate this I just committed a new method called TaskListView.getPresentations(). To proceed with the general case, please create a Sandbox patch for the presentation that copies the current content provider, something like the following. As per my comment#12 the related patch that we could take for the core is a grouping of the archive container by repository (bug 152710) which is a priority for 2.1. private ITaskListPresentation catagorizedPresentation = new ITaskListPresentation() { public IStructuredContentProvider getContentProvider() { return new <YourSubtypeOf>TaskListContentProvider(TaskListView.this); } public String getPresentationName() { return "Nested Categorization (Sandobx)"; } public ImageDescriptor getImageDescriptor() { return TasksUiImages.CATEGORY; } };
Created attachment 74097 [details] mylyn/context/zip
Mik, the change you just made on PresentationDropDownSelectionAction is very very bad idea, so as the static methods in the TaskList class. I should remind you about still unresolved issue that been requesting allowing multiple instances of the Task List view and stuff you've just added directly hurt it. I am not quite following your logic about presentations. According to your last comment they are experimental feature, then why aren't they in the sandbox, but grouping has to be? Anyways, I am not exactly amused with the idea of using copy/paste stuff, especially for such thing as content provider.
(In reply to comment #17) > Mik, the change you just made on PresentationDropDownSelectionAction is very > very bad idea, so as the static methods in the TaskList class. I should remind > you about still unresolved issue that been requesting allowing multiple > instances of the Task List view and stuff you've just added directly hurt it. As indicated on the Javadoc for that method it is temporary and I disagree that it is a bad idea because it is an interim solution on an internal class that makes it easy to add custom presentations and will be trivial to address if we provide multiple instances of the Task List view. Once we have had a chance to modularize content providers and make ITaskListPresentation API we will support adding presentations via extension point (as mentioned on the corresponding javadoc and comments on TaskListView). > I am not quite following your logic about presentations. According to your last > comment they are experimental feature, then why aren't they in the sandbox, but > grouping has to be? Anyways, I am not exactly amused with the idea of using > copy/paste stuff, especially for such thing as content provider. Sorry if I was unclear. The presentations we have and the mechanism are not experimental, but one of the key reasons that we implemented them is to enable experimentation with different presentations of task list elements. Regarding copy/pasting the content provider, you should be able to do a good portion of what you want via overriding parts of it and avoid copy/paste that way. As you know I feel strongly about avoiding copy/paste at all costs, but until we fix up the content provider architecture and fix its modularity this should be the best option. It will also enable changing the content in a way that's specific to your presentation (e.g. not showing query nodes at all, or merging multiple query nodes into a single one).
I see where are you going and I don't like that. In my opinion presentation should only show existing things differently. However grouping is a global property (unless it is done at the query level, which I haven't been suggesting and which would even worse fit into the presentation stuff) and aggregating multiple multiple queries into one is a completely separate story. The reason I don't think grouping and aggregating query should be done trough presentations is that they both have additional settings, which will be confusing to have across presentations and also like I mentioned before, it does make sense to group tasks in any presentation. Am I still missing something? Also note that this report is one of the most voted non-connector related enhancements.
I forgot to mention that getPresentation() method name does not suggest that it could be used for adding presentations like its javadoc states.
Correct, this is a temporary method name and in general we do not provide API that returns a modifiable list as is the case for this experimental method.
Created attachment 76010 [details] reimplemented grouping with custom presentations I had to introduce TaskGroup subclass of the AbstractTaskCategory. I think it will be useful for other kinds of grouping (i.e. connector specific stuff).
Created attachment 76011 [details] mylyn/context/zip
Any clue when somebody would have chance to look at this patch? I have some conflicting changes already...
I'm leaving for Mik to review this one Eugene since he has been active on this report and is the current assignee. I don't expect to see him online until early next week.
thanks for the update Rob
Patch reviewed and almost ready to apply. The appending of the number of children to the label of the parent is non-standard, so I would like to remove it. Also, is there a good driver for having grouped by Scheduled and Due? I think that those should be the responsibility of the Scheduled presentation, which needs some improvement. we can chat more about this on the call.
Scheduled presentation don't allow to see what parent bucket that group belong to (project or query) and it also don't support grouping by Due. Anyways, the major reason to have those grouping is to allow to support changing the corresponding attributes using drag and drop.
Mik, I am not quite fascinated with what you are doing with this patch. You've made several commits from this patch code under completely unrelated tasks, effectively loosing and in result lost some of functionality in the label provider class. Also, you should have brought to the discussion if TaskGroup class should be internal or not (just to pay some respect to the author of the patch). By moving it into the internal package you practically forcing integrators to use internal API if they need to build something around task grouping.
Today's commit of this was accidental, I've had it in an outgoing change set all week and got caught by bug 184963. Will post discussion on patch progress here, since I'm not done with review. Yup, I know about the omission from the label provider. Regarding the move of TaskGroup, I'm not ready to make it API yet because of overlap with TaskCategory (final and internal) a variant of which might become API. Can I get rid of the following methods in TaskGroup? The first does nothing and the second mixes presentation with the data structure: @Override public Set<AbstractTask> getChildren() { return super.getChildren(); } @Override public String getSummary() { return summary + " / " + super.getChildren().size(); }
I am not really concerned about TaskCategory, because it have no meaningful semantics and groups completely random tasks opposed to TaskGroup. You can put a warning that class may change, same way you've done with some methods on the TaskList view. Ok to remove these methods, but it would be nice to make label provider to show child count for TaskGroup until bug 199345 is fixed, especially because this is a sandbox functionality and it won't appear on the common UI.
Warning notes added to those classes, and pointer added to pending changes in Porting Guide. Most changes are committed now. I was hoping to have this fully incorporated into the Sandbox today but ran out of time due to the re-implementation required on bug 199342. These additional presentations will have to be refactored around the new extension point. Please post here if anything about the new extension point does not meet your needs for this bug. Also, note that I would like to add an integer-based importance ranking to presentations so that we can keep "Categorized" on top.
I've made patch with the refactored presentation, but instead of attaching it to the bug report I accidentally committed it, including change in the TaskElementLabelProvider to show child count for TaskGroup nodes. Feel free to roll back these changes if they don't match your expectations. I am sorry about the side effects caused by the extension point reader, but the main rationale for using content provider in the extension point instead of abstract presentation, was to eliminate need in implementing presentation class, which is really redundant. Also, with the current abstract class presentation is also not pretty because in some cases presentation id is not known up front. Id should be set from the extension point instead of hardcoding it in the presentation contructor. Ok for adding integer ranking.
Will review next Monday.
(In reply to comment #34) > Will review next Monday. Missed this due to other catch-up, reviewing today.
Patches revised, made the following changes: * Added the boolean notion of whether a presentation is primary (see extension point doc). I think that this is more clear in the UI than a priority based sorting, since it just causes a separator to be added. * Changed the icon for the new presentations to disambiguate them and added "(Experimental)". * Removed the scheduled and due presentations for now, since they overlap with the Scheduled presentations and I think we should iterate on the existing 3 before adding more. My main question now is why these presentations are grouped by category/query? I'm still not clear on the use cases for all the presentations, but for one like "by Owner" I see more benefit in excluding the query nesting than including it. For the "by Repository" one the nesting does not make sense for query nodes, but I guess it could make sense for categories? Have you considered removing the category/query nesting?
Created attachment 77933 [details] mylyn/context/zip
(In reply to comment #36) > Patches revised, made the following changes: > * Added the boolean notion of whether a presentation is primary (see extension > point doc). I think that this is more clear in the UI than a priority based > sorting, since it just causes a separator to be added. great idea > * Changed the icon for the new presentations to disambiguate them and added > "(Experimental)". there is already standard icon for groups in Eclipse - 3 colored bars, I think it is used in a few places, including help UI, but I couldn't find its source > * Removed the scheduled and due presentations for now, since they overlap with > the Scheduled presentations and I think we should iterate on the existing 3 > before adding more. Like I've been saying before, existing presentations don't give "scheduled" slicing per query/category and there is no presentation that shows "due" date. This is extremely useful with connectors that do support "due" on the server side (like JIRA does) > My main question now is why these presentations are grouped by category/query? Because it does give useful context, especially for those who are working or monitoring more then one project at a time. Those projects could actually have same developers and it doesn't make sense to group them across the projects. Also note that with this stuff enabled some of the "recommended" queries doesn't make sense anymore (i.e. one-query-per-developer thing) because much easier setup is available (one query per project + grouping by owner). > I'm still not clear on the use cases for all the presentations, but for one > like "by Owner" I see more benefit in excluding the query nesting than > including it. For the "by Repository" one the nesting does not make sense for > query nodes, but I guess it could make sense for categories? Have you > considered removing the category/query nesting? I really don't like idea of any special rules or exceptions for those things. Also, there is also queries that work across repositories. See bug 195047 (which is btw waiting on your feedback)
Almost forgot. Can you please move TaskGroup back out of the internal packages. BTW, it is minor, but there is no point to keep separate collections for presentations. It is rather confusing to split their elements this way (kind of mixing data and presentation of the presentation drop down).
(In reply to comment #39) > Almost forgot. Can you please move TaskGroup back out of the internal packages. TaskGroup is not ready to be API yet, because we have to consider the overlap with TaskCategory as previously discussed. When applying the patch I added an entry on this to: http://wiki.eclipse.org/Mylyn_Porting_Guide Please feel free to add a bug for making TaskGroup (or a variant) API if you would like to see one of these be public in the first part of the 3.0 cycle. > BTW, it is minor, but there is no point to keep separate collections for > presentations. It is rather confusing to split their elements this way (kind of > mixing data and presentation of the presentation drop down). Yup, had the same thought. But it's internals that need refactoring anyway, and the (internal) API doesn't expose the fact that there are two collections. > there is already standard icon for groups in Eclipse - 3 colored bars, > I think it is used in a few places, including help UI, but I couldn't find its source I belive the meaning of that icon is along the lines of category/tag/categories/label. Regarding your other points on comment#38, I think that we need to have a design discussion about the next direction for this. For example, I've always seen considerable benefit to the notion that you simply point your query at a project and then you see all tasks grouped by each person on that project. But that's only one point in the design space of how the UI should encourage certain queries and groupings, while remaining flexible enough for expert usage. I've added an item to the agenda for the next conference call.
(In reply to comment #40) > > there is already standard icon for groups in Eclipse - 3 colored bars, > > I think it is used in a few places, including help UI, but I couldn't find its source > I believe the meaning of that icon is along the lines of > category/tag/categories/label. True. Though those groups are sort of categories and they will make even more sense when/if we'll have some drag and drop support between groups. > Regarding your other points on comment#38, I think that we need to have a > design discussion... [skipped] Mik, this is really tiring and simply ridiculous. We are talking about sandbox features here. Why don't you just drop it into the sandbox and then discuss it for as long as you like?
(In reply to comment #41) ... > Mik, this is really tiring and simply ridiculous. We are talking about sandbox > features here. Why don't you just drop it into the sandbox and then discuss it > for as long as you like? I am working with the premise that the goal was to get this out of the Sandbox, and instead of having a dump of every property that we have drive a grouping focus on identifying some use cases and improving the UI so that we can get enough feedback on this to improve it and make it part of the distribution. If that's not the goal let me know and I won't invest more time in fixing the overhead that you are creating by providing rushed patches, without a clear UI design or discussion, that sometimes break existing functionality (e.g. presentations regression), never include tests, and introduce new API without considering or discussing implications. Since I still see promise in this functionality, and am still trying not to get too annoyed by your trying to push it through without due consideration, so I have enabled all but the "by Due date" groupings that you have provided. If anyone would like to be able to work with their Task List grouped per query and per due date please post and we can enable that too. I am trying to experiment with using the presentations for my own work and finding the result considerably too noisy (i.e. too much category-looking nesting for the benefit). I've committed a change to the grouping node to look different from the category node to see if that helps. We can iterate on the icon later but this one has the benefit of being visually quiet.
(In reply to comment #42) > I am working with the premise that the goal was to get this out of the Sandbox, > and instead of having a dump of every property that we have drive a grouping > focus on identifying some use cases and improving the UI so that we can get > enough feedback on this to improve it and make it part of the distribution. My interpretation of sandbox and "unsupported" feature is to allow users to try it first and capture feedback, but we won't be able to capture any feedback for something that is not possible to try. Besides, you don't have to move all grouping modes/presentations at once and can do it one by one. > If that's not the goal let me know and I won't invest more time in fixing the > overhead that you are creating by providing rushed patches, without a clear UI > design or discussion, that sometimes break existing functionality (e.g. > presentations regression), Well, someone have to do work while others are talking. This issue is created more then half a year ago and my contribution don't even cover the initially requested features. As you know I am trying to do stuff incrementally and introduced minor regression slipped trough your own code review process. > never include tests, and introduce new API without > considering or discussing implications. That is simply NOT true. I do include tests in some cases and constantly including related discussion topics on every other weekly meeting. It is nowhere my fault that this stuff is being pushed back and I am getting all kind of resistance for those new features. On the other hand, I remember numerous examples when you yourself been changing or removing major features without discussing them with the rest of the team. Maybe I am just taking your example... > Since I still see promise in this functionality, and am still trying not to get > too annoyed by your trying to push it through without due consideration, Are you saying that I should be thankful? > so I have enabled all but the "by Due date" groupings that you have provided. > If anyone would like to be able to work with their Task List grouped per > query and per due date please post and we can enable that too. Actually you've disabled grouping by scheduled date too. I disagree with that, but can understand this, because there is a close overlap with Scheduled presentation (which I can't get used because it don't have required context). However, I don't understand why did you disabled "due date" grouping which is not available trough any other presentation, but it is very important visualization very useful for planning. Anyways, I wonder what is your idea how anyone would know that there is a feature like that, so whey will be able to try it before they can give any feedback? > I am trying to experiment with using the presentations for my own work and > finding the result considerably too noisy (i.e. too much category-looking > nesting for the benefit). I've committed a change to the grouping node to look > different from the category node to see if that helps. We can iterate on the > icon later but this one has the benefit of being visually quiet. I don't see that in CVS. Though those presentations meant to serve purpose of the bug triaging and planning and should nicely complement multiple task list instances to facilitate analysis and support drag and drop features.
(In reply to comment #42) > I've committed a change to the grouping node to look > different from the category node to see if that helps. We can iterate on the > icon later but this one has the benefit of being visually quiet. The new icon is less noisy but it the old icon gave the task list a more unified look: All categories had a folder icon vs. tasks that have a file like icon. I need to use this more to get a better a feeling what I prefer. Did you also remove the information about the number of tasks in each category? I found that incredibly helpful to get an idea of the load each person has for a particular release (I have a query for each milestone). Maybe we could make that decoration a configurable option for now?
(In reply to comment #44) > The new icon is less noisy but it the old icon gave the task list a more unified > look: All categories had a folder icon vs. tasks that have a file like icon. I > need to use this more to get a better a feeling what I prefer. I also think that this "hierarchical" icon is out of place and been suggesting to use standard "category" icon instead. > Did you also remove the information about the number of tasks in each category? > I found that incredibly helpful to get an idea of the load each person has for a > particular release (I have a query for each milestone). Maybe we could make that > decoration a configurable option for now? There is a bug 199345 for that and I though we agreed to keep number of elements on the group nodes until bug 199345 is resolved.
(In reply to comment #45) > I also think that this "hierarchical" icon is out of place and been suggesting > to use standard "category" icon instead. I assume you mean the folder icon used by categories? I mentioned the problems with that (groupings != categories) but I can put it back if you guys prefer it, since this is all experimental. > There is a bug 199345 for that and I though we agreed to keep number of elements > on the group nodes until bug 199345 is resolved. What I said is that the number of nodes should not be returned as the label of the model element. If you want to append it create a Platform decorator for the category groupings and add that to the Sandbox. I tried using various groupings for a week but found that they typically added additional nodes without being sufficiently useful (e.g. often very few children under a node right under a query) so I'm back to categories. Is anyone working regularly in this mode? If so could you please describe how you're using it (e.g. which grouping, in Focused mode or not).
Created attachment 78670 [details] suggested icon (In reply to comment #46) > I assume you mean the folder icon used by categories? I mentioned the problems > with that (groupings != categories) but I can put it back if you guys prefer > it, since this is all experimental. Here is icon I am suggesting for group nodes > What I said is that the number of nodes should not be returned as the label of > the model element. If you want to append it create a Platform decorator for > the category groupings and add that to the Sandbox. It wasn't coded in the model, but label been constructed by hardcoded implementation in the label provider, which been recently removed. > I tried using various groupings for a week but found that they typically added > additional nodes without being sufficiently useful (e.g. often very few > children under a node right under a query) so I'm back to categories. Is > anyone working regularly in this mode? If so could you please describe how > you're using it (e.g. which grouping, in Focused mode or not). I am not using these grouping all the time, but find it quite useful when planning and triaging. Also, to narrow down task list context I often use "go into" and that helps with nesting as well as with quick search.
Any thoughts on the icon in my last comment? I think the current one is really weird, and because of the thin lines it look like another letter.
That icon is intended to mean category which isn't perfect, but the current icon is pretty clearly worse because it means presentation. RSSOwl does or did make similar use of the category icon (though maybe for tagging) and I found it reasonable when I used to use it there. What's good about that icon is that it is nice looking and relatively meaningless, which is helpful because it corresponds to different kind of objects. Applied.
Thanks Mik
So, what is the plan about grouping by other attributes specific to connector or class of connectors (grouping by project/component is particularly interesting). Should this bug depend on bug 199818 that is one of the possible solutions for such grouping?
Because the UI implications for the Task List are so significant, and because some of the use cases are more about queries for the purpose of planning than about reorganizing the Task List, here's how I propose we proceed. Instead of adding these presentations into the Task List right now, we make each of the Groupings that are currently added by the Sandbox (other than Incoming) work for the Search view. This will both provide a useful feature (e.g. query all Mylyn 2.2 bugs and view by owner) and it will give us a way of experimenting further with groupings. I think that we could make groupings available as part of Search for Mylyn 2.2, as long as the additional groupings do not show up in the Task List for 2.2. Once that's done, and we all have some usage mileage on that, it should give us enough information to figure out the split between Task List and Presentations and planning/search/groupings in order to figure out the best combination of UI for 3.0. Thoughts?
While grouping in Search view could be useful, it is much less useful then grouping in the Task List. Also note that challenges with implementing grouping in the Task List won't be the same as for the Search view, so as the actual use cases and the whole purpose for grouping is different.
Good point, the use cases are different. However, for reasons mentioned at the end of comment#52 I think that this is important to try. In general I find that Mylyn does not make good enough use of the Search view for showing the user a useful representation of a temporary query for activities such as planning. While the Search view is static and requires a button push to refresh results, it is still a pretty good UI to be used for this purpose. For example, I do almost all the Mylyn planning with it, because I don't want to pollute my Task List with too much temporary planning info. In order to get more insight on the split between the Task List view UI and the Search UI, and then unblock progress on this bug. I have created bug 209407.
That is the strangest thing. By using Search view you are just working around the grouping limitations of the Task List view. Also, like I mentioned before, "refresh" on Search view results is quite useless because it doesn't allow to tweak query criteria (you can only create new search, but not edit the existing one)
After last weekly conf call I've got an impression that project vision is changing and functionality requested on this bug report is not relevant anymore. Also, there are plans to drop currently implemented alternative grouping for Mylyn 3.0.
What gave you the impression that the project vision is changing? I wonder if I have miscommunicated something, but as far as I can tell all of my comments on this bug are in line with what I tried to communicate to you on the call. Since there seems to be some misunderstanding of the vision and/or scope of the project, let me know what that is as I would like to document it on the wiki and solicit feedback. Maybe the problem is that we have not been expicit enough about how planning tools overlap with the scope of Mylyn? But at every opportunity we have indiciated that we cannot take on fancy planning facilities, or turn the Task List into a planning tool, without a significant increase in the resources on the project.
Mik, my point is that advanced grouping and tagging features are property not only planning tool, those kind of things help awareness on the project and facilitate team collaboration (for example I found dozen stale issues using special grouping modes in the task list). Initially you were open about adding grouping features to the task list, but lately that been changed, that is what I call change in the project vision. Also, I am not sure how task-related project can get away without supporting planning features, unless they been reserved for commercial products, but that will be very sad for the whole community.
(In reply to comment #58) > Initially you were open about adding grouping features to the task list, but > lately that been changed, that is what I call change in the project vision. Eugene: I proposed that we experiment with these features, and we have put substantial cycles into experimenting with them, and there is still some promise to integrate some of these ideas, and this bug is still scheduled for 3.0. I appreciate that you blogged about this in order to get votes on it. However, unfortunately you and I have not converged in how we can add this feature to Mylyn in a way that is both usable and something that's within the project's ability to support. > Also, I am not sure how task-related project can get away without supporting > planning features, unless they been reserved for commercial products, but that > will be very sad for the whole community. Planning features beyond the Task List's facilities have never been in scope for the project. We experimented with the Task Activity view, and incorporated this schedule-based point of view into the Task List, but it is clear that we do not have the resources to support full on planning tools beyond the basic personal planning that the Task List is intended for. You have made similar criticisms on other bug reports as well and for the non-technical parts bugs are not the right place for them. You are definitely free to share your opinion with others, in case there are others in the community who feel the same way, and should consider sending a complaint to the mylyn-dev mailing list that you don't agree with the scope or vision of the project, or with that you don't agree with how Tasktop committers prioritize addressing the communities' needs, or what your other ideas are for drawing additional resources to the project to support your particular priorities.
Need to defer: http://wiki.eclipse.org/index.php/Mylyn/3.0_Plan#Deferred_Items
If it's too hard to add used defined depth grouping, could you add a fixed size (==1) grouping on 1 field only? It would be better than categories, since it would be "dynamic". I'd love to see a "Group by" menu with target milestone, version, assigned, etc items. Right now i have to modify my queries or make a lot of them.
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
