Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Mylyn/Plan/2.0"

 
(29 intermediate revisions by 6 users not shown)
Line 1: Line 1:
'''This is an early draft and not yet ready for comment.'''  
+
[[Category:Mylyn]]
 +
Edit this document for corrections or clarificationsTo discuss adding or removing items please use [https://bugs.eclipse.org/bugs/show_bug.cgi?id=173121 bug 173121].  Also see the [[Mylyn 3.0 Plan]].
  
 
= Milestones =
 
= Milestones =
Mylar milestones are released 1 week after [http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html Eclipse milestones].
+
Mylar milestones are released 1 week after [http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html Eclipse milestones].  Click to view open bugs.  Each end-user release supports Eclipse 3.2 and 3.3.
 
* 2.0M1: February 16, 2007
 
* 2.0M1: February 16, 2007
 
* 2.0M2: March 30, 2007
 
* 2.0M2: March 30, 2007
* 2.0M3: May 11, 2007
+
* 2.0M3: May 11, 2007  
* 2.0RC1: June 15, 2007
+
* <s>2.0RC0: June 8, 2007 (API freeze, no end-user release)</s>
* 2.0: June 29, 2007
+
* 2.0RC0: June 18, 2007 (RC scheduled changed due to project rename)
 +
* 2.0RC1: June 20, 2007
 +
* 2.0RC2: June 22, 2007
 +
* 2.0RC3: June 26, 2007
 +
* [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Tools&product=Mylyn&target_milestone=2.0&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= 2.0: June 29, 2007]
  
= Platforms =
+
'''RC Ramp down plan for [[Europa_Simultaneous_Release | Europa]]''': after RC0 is produced RCs will be produced weekly until the 2.0 release. In the RC phase only bugs marked P2 or higher or severity major or higher will be fixed. APIs will not change except to address critical fixes.  Any API additions or changes will be summarized in an email sent to mylar-dev.
* Eclipse 3.3: Mylar 2.0 and future Mylar releases
+
 
* Eclipse 3.2: Mylar 2.0 will be the the end-of-life for 3.2 branch
+
= Scope =
* Requires Java 5 and later
+
 
 +
The first goal of Mylar is to make task and context management seamlessly integrated with the Eclipse Platform by providing rich and extensible frameworks for task repository connectors, structure bridges and team support.  The second goal is to provide a reference implementation of the Task-Focused UI for the Eclipse SDK. This includes structure bridges for the artifacts supported by the SDK which include Java, PDE, Ant and generic files.  It also includes the Bugzilla Connector as the reference task repository implementation, and CVS integration as the reference team support.  Additional features can be considered based on the availability community contributions and resources.
  
 
= Priorities =
 
= Priorities =
Committers will prioritize bugs without external contributions (i.e. patches) in the following order:
+
 
# Tasks framework & API
+
In addition to using the planned themes listed below, we need to continue prioritizing the ongoing input of our growing user community.  Committers should prioritize bugs in the following order.  This order need not be used if a bug contains a community contribution of a patch, in which case the [http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Contributing_patches quality of the patch] determines the priority.
# Task List and Task Editor UI
+
# Frameworks & APIs: Tasks, Context, Team, Monitor, headless use
# Task-Focused UI
+
# UI: Tasks List, Task Editor, Task-focused UI
# Context framework & API
+
# Connectors: Bugzilla (reference implementation), Trac (committer supported), JIRA (community supported)
# Connector improvements
+
 
 +
= Platforms =
 +
* Eclipse 3.3: supported
 +
* Eclipse 3.2: supported, post 2.0 maintenance builds only
 +
* Java 5 or later required
  
 
= Themes =
 
= Themes =
 +
 +
Legend: in progress, <font color=green>completed</font>, <font color=gray>optional</font>
  
 
== Task List ==
 
== Task List ==
  
* '''Support date view in Task List.'''  A common way of organizing tasks to work on in the current week is by day.  We should support this by integrating the Task Activity view's date range container presentation with the Task List. (147084)
+
* <font color="green">'''Support date view in Task List.'''  A common way of organizing tasks to work on in the current week is by day.  We should support this by integrating the Task Activity view's date range container presentation with the Task List. (bug 147084)</font>
  
* '''Support integration with planning/calendaring tools.'''  Many task repositories have facilities for task planning in the form of milestones, due dates, and other organizations of tasks.  The Task List and Task Editor should support such extensions, for example, allowing the Task List to be organized by milestone. (Calendaring, privacy controls) (e.g. 152490).
+
* <font color=green>'''Support integration with planning and calendaring tools.'''  Many task repositories have facilities for task planning in the form of milestones, due dates, and other organizations of tasks.  The Task List and Task Editor should support such extensions, for example, allowing the Task List to be organized by milestone.  (e.g. bug 152490).</font> [dates supported, alternate models post 2.0]
  
* '''Support working set groupings.'''  A Task List that includes projects from multiple "working spheres" (e.g. Project A, Project B, Personal) can become unwieldy and distractingIntegration of top-level working sets could address this.
+
* <font color=green>'''Support task dependencies.'''  Many tasks are related to other tasks, whether it's because they should be worked on in sequence or are subtasks.  We should make these dependencies explicit in the Task List and Task Editor(bug 137543)</font>
  
* '''Support task dependencies.'''  Many tasks are related to other tasks, whether it's because they should be worked on in sequence or are subtasks.  We should make these dependencies explicit in the Task List and Task Editor.  (137543)
+
* <font color="green">'''Support working set groupings.'''  A Task List that includes projects from multiple "working spheres" (e.g. Project A, Project B, Personal) can become unwieldy and distracting.  Integration of top-level working sets could address this.  (bug 153573)</font> 
  
 
== Task Editing ==
 
== Task Editing ==
  
* '''Increase Task Editor information density'''.  The task editor is a very frequent target of interaction, and we need to continue streamlining itWhen opened it should show the user the most relevant information with minimal clicking and scrolling required. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=158921 158921]).
+
* <font color="green">'''Improve task activity timing.''' We currently have a task activity mechanism, but it is not explicit enough, and does not capture time spent outside of the workbenchIt should also be extensible to OS-specific monitoring. (bug 135668).</font>
  
* '''Streamline task creation.'''  Make it easier to create tasks, fork them, or promote local tasks to repository tasks.  (154896, 152211)
+
* <font color=green>'''Increase Task Editor information density'''. The task editor is a very frequent target of interaction, and we need to continue streamlining itWhen opened it should show the user the most relevant information with minimal clicking and scrolling required. (bug 158921).</font>
  
* '''Provide task workflow mechanism.'''  There are many common workflows, such as commit/complete/deactivate.  We should provide a mechanism for specifying and executing task-related workflows.  This requires direct editing of task data (i.e., without editor submission).  (160780, 124224)
+
* <font color=gray>'''Provide task workflow mechanism.'''  There are many common workflows, such as commit/complete/deactivate.  We should provide a mechanism for specifying and executing task-related workflows.  This requires direct editing of task data (i.e., without editor submission).  (bug 160780, bug 124224)</font>
  
* '''Improve task activity timing.''' We currently have a task activity mechanism, but it is not explicit enough, and does not capture time spent outside of the workbench.  It should also be extensible to OS-specific monitoring. (135668).
+
* <font color=gray>'''Streamline task creation.''' Make it easier to create tasks, fork them, or promote local tasks to repository tasks. (bug 154896, bug 152211)</font>
  
 
== Task Repositories ==
 
== Task Repositories ==
  
* '''Make offline cache faster and more robust.'''  The offline cache is currently one large serialized file.  We should make it more robust so that changes to connectors and the framework do not cause the offline data to be cleared.  This should make it possible to put a repository into offline mode permanently, and never lose the task data. (165809)
+
* <font color=green>'''Make offline cache faster and more robust.'''  The offline cache is currently one large serialized file.  We should make it more robust so that changes to connectors and the framework do not cause the offline data to be cleared.  This should make it possible to put a repository into offline mode permanently, and never lose the task data. (bug 165809)</font>
  
* '''Improve connectivity problem and performance handling.'''  Lack of or degraded connectivity should be transparent, and jobs should be cancellable. (165833)
+
* <font color=green>'''Improve connectivity problem and performance handling.'''  Lack of or degraded connectivity should be transparent, and jobs should be cancellable. (bug 165833)</font>
  
* '''Improve consistency between local and repository tasks.'''  Need to consider how to promote task between local and repository, and whether local tasks should be a kind of repository.  (12431)
+
* <font color=green>'''Improve synchronization control'''. Consider allowing synchronization to be controlled per repository (bug 165473), and allowing repositories to be put into offline mode (bug 165809).</font
  
* '''Provide standard XML for for tasks.'''  We should create a canonical and extensible XML for for tasks that we use for retrieving task dataConnector providers returning this form would not need custom attribute mappings.
+
* <font color=green>'''Improve consistency between local and repository tasks.'''  Need to consider how to promote task between local and repository, and whether local tasks should be a kind of repository(bug 124321)</font>
  
* '''Improve synchronization control'''. (offline mode for repositories bug 165809, finer-grained control bug 165473)
+
* <font color=gray>'''Provide standard XML for tasks.''' To make creating connectors easier, we could provide a canonical and extensible XML for for tasks that we use for retrieving task data.</font>
  
* '''Streamline task searching'''.  It is currently impossible to search through local and cached task data.  We could improve the search experience by providing Google-style syntax in the ''Task List'' find box, e.g. severity=critical.  (bug 163341)
+
* <s>'''Streamline task searching'''.  It is currently impossible to search through local and cached task data.  We could improve the search experience by providing Google-style syntax in the ''Task List'' find box, e.g. severity=critical.  (bug 163341)</s> [deferred post 2.0, dependent on Platform, relying on Ctrl+H search instead]
  
 
== Task-Focused UI ==
 
== Task-Focused UI ==
  
* '''Provide preview and editing of task context.''' For submitting and retrieving contexts, or wanting to inspect a context for a non-active task, we should provide a preview pane.  This should also support operations such as merge and element deletion.  (bug 107259)
+
* <font color="green">'''Provide preview and editing of task context.''' For submitting and retrieving contexts, or wanting to inspect a context for a non-active task, we should provide a preview pane.  This should also support operations such as merge and element deletion.  (bug 107259)</font>
  
* '''Preserve element identity through refactoring.'''  Currently only the active context participates in refactoringWe either need to maintain a dependency map to update the element handles of inactive contexts, or migrate them when they are activated, via the refactoring history. (164243)
+
* <font color=green>'''Support debugging views'''. This includes improved filtering of the thread tree, and automatic toggling/loading of breakpoints with task context.<font color=green> [thread tree supported, breakpoints post 2.0]
  
* '''Support debugging views'''.  This includes improved filtering of the thread tree, and automatic toggling/loading of breakpoints with task context.
+
* <font color=gray>'''Provide task context relation navigation.''' The ''Active Search'' that we deprecated provided relationship navigation.  This facility could be re-introduced with an in-place view of relations between elements, e.g. calls, implements.  (bug 104052)</font>
 +
 
 +
* <font color=gray>'''Preserve element identity through refactoring.'''  Currently only the active context participates in refactoring. We either need to maintain a dependency map to update the element handles of inactive contexts, or migrate them when they are activated, via the refactoring history.  (bug 164243)</font>
  
 
== General ==
 
== General ==
  
* '''Generalize task and context storage mechanisms.'''  Our API currently specifies files and paths as the storage mechanism, but it should be general, to allow for alternate mechanisms such as server-based storage.
+
* <font color=green>'''Hyperlinking everywhere'''.  Wherever structured elements show up, we should be hyperlinking them (e.g. bug 165827)</font>
 +
 
 +
* <font color=green>'''Improve error handling and resolution.'''  When an error happens, we should do automatic duplicate detection, and if no duplicate is found prompt to submit a bug to the failing plug-in.</font> [submission and detection are still on-demand, not automatic]
  
* '''Improve error handling and resolution.'''  When an error happens, we should do automatic duplicate detection, and if no duplicate is found prompt to submit a bug to the failing plug-in.
+
* '''Generalize task and context storage mechanisms.'''  Our API currently specifies files and paths as the storage mechanism, but it should be general, to allow for alternate mechanisms such as server-based storage. (bug 171346)
  
* '''Improve representation of people'''.  Support real names, selecting CCs, content assist for fields with people.  The user's identity should be represented in the UI (e.g. different icon when user appears in the CC list).
+
* <font color=green>'''Improve representation of people'''.  Support real names, selecting CCs, content assist for fields with people.  The user's identity should be represented in the UI (e.g. different icon when user appears in the CC list).</font>
  
* '''Hyperlinking everywhere'''.  Wherever structured elements show up, we should be hyperlinking them (e.g. bug 165827)
+
* <font color=green>'''Personal monitoring and usage sharing'''.  We require data from the Mylar monitor to inform our UI design.  We should also make this data available to others, since it will include general Eclipse usage statistics.  In order to provide users with an incentive to share their (anonymous) usage data we should include personal interaction monitoring facilities.</font>

Latest revision as of 12:27, 16 June 2008

Edit this document for corrections or clarifications. To discuss adding or removing items please use bug 173121. Also see the Mylyn 3.0 Plan.

Milestones

Mylar milestones are released 1 week after Eclipse milestones. Click to view open bugs. Each end-user release supports Eclipse 3.2 and 3.3.

  • 2.0M1: February 16, 2007
  • 2.0M2: March 30, 2007
  • 2.0M3: May 11, 2007
  • 2.0RC0: June 8, 2007 (API freeze, no end-user release)
  • 2.0RC0: June 18, 2007 (RC scheduled changed due to project rename)
  • 2.0RC1: June 20, 2007
  • 2.0RC2: June 22, 2007
  • 2.0RC3: June 26, 2007
  • 2.0: June 29, 2007

RC Ramp down plan for Europa: after RC0 is produced RCs will be produced weekly until the 2.0 release. In the RC phase only bugs marked P2 or higher or severity major or higher will be fixed. APIs will not change except to address critical fixes. Any API additions or changes will be summarized in an email sent to mylar-dev.

Scope

The first goal of Mylar is to make task and context management seamlessly integrated with the Eclipse Platform by providing rich and extensible frameworks for task repository connectors, structure bridges and team support. The second goal is to provide a reference implementation of the Task-Focused UI for the Eclipse SDK. This includes structure bridges for the artifacts supported by the SDK which include Java, PDE, Ant and generic files. It also includes the Bugzilla Connector as the reference task repository implementation, and CVS integration as the reference team support. Additional features can be considered based on the availability community contributions and resources.

Priorities

In addition to using the planned themes listed below, we need to continue prioritizing the ongoing input of our growing user community. Committers should prioritize bugs in the following order. This order need not be used if a bug contains a community contribution of a patch, in which case the quality of the patch determines the priority.

  1. Frameworks & APIs: Tasks, Context, Team, Monitor, headless use
  2. UI: Tasks List, Task Editor, Task-focused UI
  3. Connectors: Bugzilla (reference implementation), Trac (committer supported), JIRA (community supported)

Platforms

  • Eclipse 3.3: supported
  • Eclipse 3.2: supported, post 2.0 maintenance builds only
  • Java 5 or later required

Themes

Legend: in progress, completed, optional

Task List

  • Support date view in Task List. A common way of organizing tasks to work on in the current week is by day. We should support this by integrating the Task Activity view's date range container presentation with the Task List. (bug 147084)
  • Support integration with planning and calendaring tools. Many task repositories have facilities for task planning in the form of milestones, due dates, and other organizations of tasks. The Task List and Task Editor should support such extensions, for example, allowing the Task List to be organized by milestone. (e.g. bug 152490). [dates supported, alternate models post 2.0]
  • Support task dependencies. Many tasks are related to other tasks, whether it's because they should be worked on in sequence or are subtasks. We should make these dependencies explicit in the Task List and Task Editor. (bug 137543)
  • Support working set groupings. A Task List that includes projects from multiple "working spheres" (e.g. Project A, Project B, Personal) can become unwieldy and distracting. Integration of top-level working sets could address this. (bug 153573)

Task Editing

  • Improve task activity timing. We currently have a task activity mechanism, but it is not explicit enough, and does not capture time spent outside of the workbench. It should also be extensible to OS-specific monitoring. (bug 135668).
  • Increase Task Editor information density. The task editor is a very frequent target of interaction, and we need to continue streamlining it. When opened it should show the user the most relevant information with minimal clicking and scrolling required. (bug 158921).
  • Provide task workflow mechanism. There are many common workflows, such as commit/complete/deactivate. We should provide a mechanism for specifying and executing task-related workflows. This requires direct editing of task data (i.e., without editor submission). (bug 160780, bug 124224)
  • Streamline task creation. Make it easier to create tasks, fork them, or promote local tasks to repository tasks. (bug 154896, bug 152211)

Task Repositories

  • Make offline cache faster and more robust. The offline cache is currently one large serialized file. We should make it more robust so that changes to connectors and the framework do not cause the offline data to be cleared. This should make it possible to put a repository into offline mode permanently, and never lose the task data. (bug 165809)
  • Improve connectivity problem and performance handling. Lack of or degraded connectivity should be transparent, and jobs should be cancellable. (bug 165833)
  • Improve synchronization control. Consider allowing synchronization to be controlled per repository (bug 165473), and allowing repositories to be put into offline mode (bug 165809).</font
  • Improve consistency between local and repository tasks. Need to consider how to promote task between local and repository, and whether local tasks should be a kind of repository. (bug 124321)
  • Provide standard XML for tasks. To make creating connectors easier, we could provide a canonical and extensible XML for for tasks that we use for retrieving task data.
  • Streamline task searching. It is currently impossible to search through local and cached task data. We could improve the search experience by providing Google-style syntax in the Task List find box, e.g. severity=critical. (bug 163341) [deferred post 2.0, dependent on Platform, relying on Ctrl+H search instead]

Task-Focused UI

  • Provide preview and editing of task context. For submitting and retrieving contexts, or wanting to inspect a context for a non-active task, we should provide a preview pane. This should also support operations such as merge and element deletion. (bug 107259)
  • Support debugging views. This includes improved filtering of the thread tree, and automatic toggling/loading of breakpoints with task context. [thread tree supported, breakpoints post 2.0]
  • Provide task context relation navigation. The Active Search that we deprecated provided relationship navigation. This facility could be re-introduced with an in-place view of relations between elements, e.g. calls, implements. (bug 104052)
  • Preserve element identity through refactoring. Currently only the active context participates in refactoring. We either need to maintain a dependency map to update the element handles of inactive contexts, or migrate them when they are activated, via the refactoring history. (bug 164243)

General

  • Hyperlinking everywhere. Wherever structured elements show up, we should be hyperlinking them (e.g. bug 165827)
  • Improve error handling and resolution. When an error happens, we should do automatic duplicate detection, and if no duplicate is found prompt to submit a bug to the failing plug-in. [submission and detection are still on-demand, not automatic]
  • Generalize task and context storage mechanisms. Our API currently specifies files and paths as the storage mechanism, but it should be general, to allow for alternate mechanisms such as server-based storage. (bug 171346)
  • Improve representation of people. Support real names, selecting CCs, content assist for fields with people. The user's identity should be represented in the UI (e.g. different icon when user appears in the CC list).
  • Personal monitoring and usage sharing. We require data from the Mylar monitor to inform our UI design. We should also make this data available to others, since it will include general Eclipse usage statistics. In order to provide users with an incentive to share their (anonymous) usage data we should include personal interaction monitoring facilities.

Back to the top