Revision as of 00:45, 27 August 2007

Please note that this is VERY ROUGH DRAFT and changes are still in progress. To propose items or discussion the mylyn-integrators mailing list. Also see the Mylyn 2.0 Plan.

Milestones

Mylar milestones are released 1 week after Eclipse milestones. Click to view open bugs. Dates will be listed in the Mylyn Calendar (view as iCal or html).

• 2.1M1: August 27, 2007
• 2.1: October 6, 2007
• 2.2M1: November 17, 2007
• 2.2: January 12, 2008
• 2.3M1: February 23, 2008
• 2.3: March 5, 2008
• 3.0RC: May 17, 2008 (API Freeze)
• 3.0: Jun 28, 2008 (view all open 3.0 bugs)

Scope

The first goal of Mylyn 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 and 3.4 Milestones (only latest milestone supported at time of release)
• Java: JRE 5.0 or later required
• Operating Systems: all supported by Eclipse

Theme Brainstorming

Legend: in progress, completed, optional

Theme dump from the 2007-07-24 conference call

Supporting Integrators

• Headless use
• Tasks framework: the usual
• Team framework: making it more generic, Platform/Team contributions
• Context framework: ohter langauges WTP, DLTK

EK: componentize task editors

Task List usability

• Archive category
• Uncategorized category
• Subtasks
• Notifications
• Task editor workflow
• Streamline task creation

EK: multiple instances of Task List view to facilitate drag and drop and different presentations; more flexible ways to group tasks without creating many queries (to make it easier to deal with and observe many issues; it is also one of the most voted requests); improve task editor usability (i.e. scroll to recent changes, sync editor with outline and other views); tagging tasks and creating custom task hierarchies; improving task list storage for incremental updates and allow full text search (perhaps using lucene)

Task Activity

• Lots of fixes needed

EK: clean up bugs related to context interaction with the IDE. In some cases Java code completion is less relevant with context activated; Package Explorer show random elements (like class patch containers), or don't clean the parent nodes after temporary/transient child got removed from context; inconsistency between "remove from context" menu and keyboard shortcuts (the latter work on stuff that don't have menu)

Task List models

• Content providers vs. filters and groupings (e.g. subtasks)
• Better support for presentations
• Generic schema vs. connector-specific schema

Synchronization

• Synch priority
• Network I/O responsiveness, cancellability
• Incremental synch architecture

Task schema

• common schema
• generic XML format for repository task data and repo configuration

EK: the above is either the same or need to be clarified. Is these formats intended for import/export or for working with 3rd party repositories. The former probably better to address with public API instead of relying on the schema.

Task context (degree-of-interest model)

• Surfacing relationships
• Improving bookkeeping
• Preserving element identity: refactoring, migrating handles
• Composite contexts for subtasks and working sets

EK: previewing context without activation; preserve user identity within context to see context evolution when multiple people working on the task; context comparison; recovering the task context from global history and generally improve "clean task" story.

Internal process

• Explicitly tag bug reports needed by advanced use cases or committers?