Community
Participate
Working Groups
Please allow for multiple tasks to be active at one time (configurable in preferences?). Mik said in an email response that the original design for Mylyn allowed for multiple active tasks. You can see this in much of the underlying data structure, such as TaskList. However, much of the functional logic now assumes that one and only one task can be active. One particular example is TaskListManager.activateTask(AbstractTask,boolean), which starts deactivating any active tasks before the specified task is activated. There is a lot of additional UI and context logic that makes "getActiveTask()" type of calls, as well. We'd like Mylyn's logic to be more conditional; something more like "getActiveTasks()", which would return lists of 0..*. Here's why: the users on my project are not developers. They're like legal researchers who spend their time perusing content in support of multiple, possibly interrelated tasks. Think of each task as an individual case. They are queried from a repository that is actual a Weblogic-based BPM. Our researchers are "multi-taskers." Any particular document may apply contextually to several simultaneously active cases. We want to tie in each researched piece of content, whether it's a PDF document, Word file, or whatever, into each task's context. Then, we want to share that context between users. We were able to circumvent the functional limitations to fit the needs of our prototype. In the process, Mylyn got many accolades. Our customer loved that 80% of the functionality was provided by COTS plugins. However, we're afraid that our hacks won't last. The underlying data structures might go away if you go on assuming that users only work on one task at a time.
Thanks for the clear explanation of the use case chip. This is something that we have encountered as well, both in the programming domain and in more general knowledge work domains. There is some background on bug 137543, but I'll summarize where we're at with it. I believe that it is impossible to be working on that it is impossible for one person to be working on two things at the exact same time. What is possible is for us to be switching at a very past pace between tasks, or to be working on multiple related tasks together. For example, a lawyer could be working on two interdependent cases. I would like to see Mylyn do two things to better support this kind of work: 1) Remove all possible friction of task switching. With Mylyn 2.3 we have further sped up task switching, and will do more work in this direction for 3.0. 2) Support dependencies between contexts, just as we support dependencies between tasks. For example, a task with multiple child tasks can have the parent context include all of the child context when active, and propagate interaction to the children contexts accordingly. I think that (2) will meet the needs that you describe? It will take some more design for us to figure this out and I'm interested in hearing your input. For the time being, since you already have an implementation, the best way to manage not having your hacks break as we evolve the Task List is to provide us with some test cases for API or internals that you would like to continue to see working. We should be able to promise supporting some version of the functionality that you are using, since it is part of the current Tasks API. Let me know if you want some pointers on how to create those test cases.
Hmmm... possibly on #2. We'll have to give it some thought. Ultimately, we're trying to get to a situation in which task activation is performed automatically based on 1) the content's attributes, and 2) the task's attributes. Our users don't want to be "bothered" (their words, not ours) with manually selecting which tasks are active. For example, say the document obtained from our database is tagged with an ID correlating to "private securities" in financial law. A researcher may have been assigned as many as 10 tasks, 3 of which also correlate (among other things) to "private securities". Our customer wants the activation and applied context of these three tasks to happen automatically and behind-the-scenes. They want the user to "see" the context having been applied, and then given the opportunity to individually shift things around if it doesn't quite match (drag-n-drop, menu contributions, etc.). Above all, they want it done in an intuitive, non-intrusive way (aren't customers fun?). Mylyn goes a long way, for certain, but we're not expecting it to do the whole job. We're thinking we'll not be using the normal navigator view. Maybe quick, individual activation switching will do the trick. Thanks for the quick feedback!
Sorry, forgot to mention about the nested, parent/child task relationships. That probably wouldn't work in our case, unless we were able to create and destroy relationships between tasks on-the-fly. The relationships would only exist long enough to apply the context. That said, the previous quick-switching scenario holds the most promise.
That's a very interesting scenario Chip. I'm interest in learning more about the solution that you come up with. One thing that we have thought about is these automatic triggers for task activation. For example, in our experimental plug-ins we have an option to auto-activate tasks on open. It makes sense that in a particular domain there would be other kinds of events that could activate a task.
Another scenario in the software development domain is where there are multiple systems with Mylyn connectors in the company which are used for distinct purposes. For example, maybe a company uses Bugzilla for customer "problem reports" but Trac for development tasks/bugstracking. In this case, some "bugs" may live in two places: in the system used by support and in the system used by development. When a customer reports a bug, support creates an entry in the Bugzilla repository. When development reproduces it, they create a bug in Trac for the task. It may make sense to associate the same context to both the Bugzilla task and the Trac task at this point. Another similar example. This one is closer to the one I care about. The two systems may be the company's bug tracking system (e.g., Bugzilla) and the task/project management system (e.g., Rally). Perhaps there are several Rally tasks to fix one Bugzilla task. The development team does not create Bugzilla entries. Those are only created by support or QA. In this case, the developer may use his own system to track his work, and he may need to create tasks at a different granularity than those created by support and QA. He may want to activate the Bugzilla bug and Rally task1. Then, he finishes the first chunk of work and uses the Rally task1's context to commit/review the code. Now he works on Rally task2, but he still want the same Bugzilla bug to be active at the same time. So, eventually, the Bugzilla bug's context would be similar to the union of the context from the associated Rally tasks. It would make more sense to have good linking between the task repositories themselves, and then the developer would only have to create a context on one side (say, in Rally). Then, when he needs to see the context for a Bugzilla issue when QA fails his fix, he would check which Rally tasks are related to that Bugzilla issue. Unfortunately, that kind of linking doesn't seem to happen often in reality. Without it, the developer is probably going to want the context associated with both systems. I'm not sure whether the benefit of being able to have multiple active tasks at once is worth the added complexity to the code and to the user-visible behavior of Mylyn. :) To me, the issue is less about whether I can do two things at once than it is about whether there is overlap in the task systems (e.g., a task with subtasks). Or, in the examples I gave, task systems that express the same or similar tasks to in different ways. If you plan to solve it with dependent task contexts, did you plan to permit those links across different repositories?
The UI for this is currently out of the scope of the Mylyn Task List. The API already has some support for it. Additional extensions would require contribution or sponsored customizations (see http://www.eclipse.org/mylyn/support/).
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
