Tasktop Blog

Today marks the start of a major extension of Eclipse and Mylyn’s reach into Agile project management. We’re very pleased to announce a partnership with VersionOne to develop an Eclipse Mylyn connector for VersionOne’s Agile planning and project management platform. The Tasktop Certified VersionOne Connector will be included in Tasktop Pro and available as a plugin for any Eclipse-based IDE or as a standalone desktop application for product owners.

One of the features we will be leveraging in VersionOne is their open and extensible platform approach to project management. VersionOne’s Team and Enterprise products provide comprehensive core of agile project planning and management tools. These tools are extended with a REST web service API as well as open source SDKs for both Java and .NET to facilitate integration with the rest of an organization’s unique tool stack. This open approach has led to an impressive ecosystem of integrations with defect trackers, version control system, build systems and more.

With the upcoming Mylyn and Tasktop Pro integration, VersionOne’s interoperability will take another giant leap forward in two key ways. First, VersionOne is joining the ecosystem of 42 interoperable Mylyn connectors. This will allow development teams in complex environments to seamlessly access VersionOne alongside artifacts from other supported systems as well as move and link artifacts across systems, all from within the IDE. Second, integration with Tasktop Pro will enable VersionOne artifacts to be linked with web pages, local documents, and applications such as Microsoft Outlook.

Of course, the Connector will also allow VersionOne teams to take full advantage of Mylyn’s task-focused productivity technology to focus the interface on only the code, documents and web pages that are relevant for a given VersionOne story, defect or task.

Feature Highlights

		Access VersionOne from any Eclipse-based IDE
		Standalone desktop application with offline access to VersionOne artifacts
		Link VersionOne stories with artifacts in other Tasktop Certified repositories
		Automatic time tracking and reporting
		Task-focused interface productivity technology
		Easy installation from the Mylyn Connector Discovery listing in the Eclipse IDE

We’ve received fifty requests for VersionOne integration and look forward to releasing the connector in March, 2010. Sign up on the VersionOne Connector page to be notified of future announcements.

Today’s Tasktop Pro 1.6.1 release includes a new Mylyn connector for the Mingle 3.0 project management software from ThoughtWorks Studios, the products division of the global Agile consultancy, ThoughtWorks. The connector takes Mingle’s emphasis on team collaboration to a new level by making it effortless for team members to access and communicate around Mingle cards without leaving the IDE.

What makes our collaboration with ThoughtWorks so exciting is that it has yielded the first social network extension to the task-focused interface. Starting on a cool task? Just murmur it much as you would send a tweet. The integration with the task editor is seamless. Stuck on something? Attach your task context, murmur for help, and colleagues on the project will have instant access to the code you’re squinting at.

	Watch the Mingle Connector Video

What’s a murmur?

Mingle’s Murmurs™ support casual conversations much like Twitter or IM chats. But instead of being lost in Twitter or IM, the communication is captured on artifacts in Mingle for easy reference. With the Mingle Connector, Murmurs can be sent directly from the IDE and it’s easy to view all murmurs relevant to a particular development task or card.

 
Focus on your cards

The Mingle Mylyn Connector fully supports task-focused programming productivity. Mingle cards in the task list can be activated to automatically track and show only the most relevant source code, web pages and documents for a given card. For example, when working on a million line code base, the task-focused interface might show only the 2 files and 12 lines of code that are relevant for the bug fix in progress. When returning to the same bug after an interruption, or after lunch, a single click instantly restores the workspace to its previous state, including open editors. This means far less time is spent repeatedly searching and scrolling to find the relevant code and other information. For more on task-focused programming, watch the Tasktop for Carbide screencast which demonstrates the concepts using the Eclipse-based Carbide IDE.

 
Automate time tracking

Because Tasktop users activate their tasks or cards to benefit from the task-focused interface, the time spent on each card is already available. Each Mingle card includes a time tracking section that provides a summary of how much time was spent during a given period. Time spent can be adjusted as needed to account for meetings, design time at the whiteboard etc. before uploading the data directly to Mingle.

 
What about Twist and Cruise?

Mingle is a part of ThoughtWorks Studios’ Adaptive ALM product suite that includes Twist test automation and Cruise release management products. Further Tasktop Pro integration with Twist and Cruise will be available in March 2010. Sign up to be notified about further integration on the ThoughtWorks Studios Connector page.

 
Try it

The Mingle Mylyn Connector is now included in Tasktop Pro. Download a free trial

If using an IDE based on Eclipse 3.5 or later with Mylyn installed, Tasktop Pro can also be installed via the Connector Discovery wizard by clicking “New Task” in the Task List toolbar and then clicking the “More Connectors…” button.

Need Mingle? Download a free Mingle trial

At the Symbian Exchange & Expo conference, I presented a talk called Coordinating contributions: lessons learned growing an OSS community, sharing my lessons learned from the AspectJ and Eclipse Mylyn communities. The Symbian Foundation has adopted the EPL, Bugzilla, and an open development model. What makes the Mylyn project an interesting data point is that with the same infrastructure, it has seen over 800 bug and enhancement reports resolved by patches from a very active contributor community. That’s around 1/7 of our bugs resolved, and falls within the top two Eclipse projects for total contribution count. While Tasktop Technologies has provided the resources for maintaining, supporting and evolving the Mylyn frameworks, we have managed to create a very permeable and successful ecosystem for contributors.

The talk broke the contribution problem up into three pillars: the modular platform that defines the landscape of interesting contributions, the incentive structure needed to drive contributors, and the collaboration tools that support the open development process. While responding questions after the presentation, I was struck by how important the extension install story is to the first two pillars.

Open platforms need easy extension install

If you release a cool tool and nobody can find or install it, does it still make a sound? Not if the sound that you’re after is the roar of broad adoption. One ingredient of an install story is the dependency management technology, which defines the modularity of extensions. In Eclipse, this is a solved problem thanks to OSGi and the Equinox P2 provisioning system.

Another ingredient is incentive structure. The Eclipse Plug-in Central site provided a web portal for listing extensions, but was disconnected from an install story. In contrast, consider the success of the market-driven incentives of Apple’s app store. Or the seamless install process of iPhone apps and Firefox add-ons. Incredible ecosystem growth can result when install technology, modularity mechanisms, and incentive structure line up. While Eclipse provides a great generic install and dependency management mechanism, as the number of Mylyn integrations grew, we realized that a limiting factor of adoption was the discovery of integrations and ease of their installation. In order to continue to support our growth and not overly bias our ecosystem to those extensions that were hosted on Eclipse.org, we needed to streamline Eclipse’s install experience for Mylyn connectors. So we created the Mylyn Connector Discovery tool.

Generalizing Mylyn Connector Discovery

Since the release of Connector Discovery release with Eclipse Galileo, the listing has grown and received consistent praise from users and integrators. We’ve since seen many requests to generalize the mechanism to other install use cases ranging from Eclipse Pulsar SDK installs to the exciting new Eclipse Marketplace effort. The SpringSource Tool Suite is a great example of how the Discovery UI can be leveraged for targeted extension install.

In response to this interest, we have generalized the code and are proposing to move it to the the Equinox P2 project, home of Eclipse install. For details on that proposal see Eclipse bug 295273. What I hope we see in the Eclipse Helios release time frame is the Discovery mechanism as P2 API for special-purpose install workflows, with extensions for Mylyn Connectors, Eclipse Marketplace and more. This Discovery install story is additionally relevant to Eclipse Rich Client Platform (RCP) install scenarios, which often need a simplified and tailored install experience.

While serving on the Eclipse board of directors, a concern I repeatedly raised was the repeated problems that arose from an incomplete install story. The great thing about being part of a meritocratic ecosystem like Eclipse, which rewards participation, is the ability to put code and resources where your mouth is.

The economics of extension listings

A tension that surfaces around shared resources is the Tragedy of the Commons. This gets discussed repeatedly in Eclipse, and can happen in vendor neutral open source ecosystems when organizations attempt to derive value from common frameworks and tools without contributing enough back. As a result, those ecosystems tend to be lead by organizations that understand commercial open source enough to act with enlightened self-interest. But with the continually growing number of Mylyn integrations, we also needed to consider companies with a shorter-term outlook. For example, like other projects, we see the pattern of vendors leveraging our frameworks in ways where they impose a significant support burden on the committers, and not contributing back in terms of patches or resources to help grow those frameworks. While I believe that an open source project like Mylyn should welcome all integrations, an indefinitely increasing support burden is not scalable and can reduce the time available for innovation. We need to avoid the Easter Island effect where everyone builds themselves self-serving heads without prioritizing the long-term health of the ecosystem within which they operate (see Easter Island/Collapse of the Ecosystem).

Discovery style extension listings provide a great opportunity to encourage meritocracy, one of the driving principles of a vendor-neutral development process like Eclipse’s, and help align the interests of a project with those leveraging on it. For good references on meritocracy see Chris Aniszczyk’s recent post. In preparation for last June’s release of the Mylyn Connector Discovery, we worked with our community to create listing criteria that achieve this balance. To paraphrase here, committers can vote you into the listing if you contribute enough to the project to offset the additional burden that you impose on the committers. If you are a vendor and are pulling your weight on the project by growing the frameworks and tools for all integrators to leverage, you can get your own section. If you have a community-oriented open source integration, committers go an extra mile and offer you UI and API reviews in order to help encourage cross-ecosystem collaborations, which can yield a long-term benefit, as evidenced by our collaborations with Mozilla. The listing criteria are open to feedback and input on Eclipse bug 279709.

To date, this meritocratic listing approach has worked extremely well for promoting high-quality extensions and contributions. It has encouraged the growth and adoption of independent efforts such as the Mantis connector, reduced the adoption bias we had of connectors that were hosted on Eclipse.org, and provided a mechanism for promoting the latest round of commercial integrations needed to grow the Mylyn user base.

With a generalized Discovery mechanism in place, I hope that we see a similar trend for other special-purpose Eclipse extensions. For example, the Eclipse Marketplace can use ranking in the Discovery listings for promoting members’ solutions. Projects like Eclipse Pulsar can make their key contributors’ mobile SDKs trivial to install. And the next round of innovative Eclipse projects can use this mechanism to help grow their ecosystem of extensions by promoting meritocracy.

I spent the early years of my career with MacOS and then Linux as my primary OS. When the focus of my work moved to tool building, I decided that I needed to use the OS that was most common in the tools’ target audience. In the Eclipse ecosystem, that’s Windows, which captures more than three quarters of Eclipse IDE downloads.

The great thing about Eclipse is that architecturally, thanks to the amazing SWT framework that IBM created, Eclipse provides a native experience on your OS of choice. But last April, when I moved my primary OS to the Windows 7 RC, I noticed two things. The first was a feeling reminiscent of when I first started using Windows XP early 2001. Windows 7 was slick, responsive, and brought the desktop client to a new level of refinement. The second observation was that Eclipse and Tasktop, which I spend the majority of my time in, looked like dated Windows XP applications.

Today we’re happy to announce that Tasktop is working with Microsoft to help make Eclipse look and feel like an exemplary Windows 7 application. It is great to see Microsoft supporting this effort, since it will impact a broad range of users of the Eclipse IDE, as well users of commercial Eclipse-based IDEs such as the SpringSource Tool Suite IDE, and Eclipse RCP applications such as Tasktop Pro for Windows. Read more about the Microsoft initiative behind this on Vijay Rajagopalan’s post on the Microsoft Interoperability blog.

The majority of Eclipse’s current Windows 7 interoperability comes from the previous efforts of the Eclipse SWT teams and from the backwards compatibility of Windows 7. So you can happily run Eclipse on Windows 7 today. This allows us to focus entirely on leveraging the new features in Windows 7 and on look-and-feel enhancements. Here are a couple of highlights of the initial scope of the effort. Note that all contributions will be made to Eclipse.org under the EPL.

Taskbar Progress (Eclipse bug 293228)

Windows 7 provides a new visual representation of progress on taskbar icons. This feature removes the need to Alt+Tab to an application just to check on the status of a long-running job, such as a download. The plan is to integrate this with Eclipse progress in order to allow some key jobs, such as a full builds and runtime launches, to indicate their status on the taskbar. We already have a working prototype of this functionality, which I’ll show later today when I arrive at Eclipse Summit Europe.

Taskbar Jump Lists (Eclipse bug 293229)

The redesigned Windows 7 taskbar allows applications to expose frequently used features or files. We plan to incorporate this with Eclipse commands and actions that will benefit from quick taskbar based access.

We have some additional enhancements planned, including updating the widget colors and styling to match the Windows 7 look. SWT walks a very careful line in terms of leveraging native widgets, following accessibility guidelines and using desktop themes. Enhancing that experience would not be possible without the technical expertise of the Microsoft Windows and Eclipse SWT teams, whom we have to thank for the high quality Eclipse on Windows experience that we have today. Thanks to this new open source collaboration, what we’ll soon have is the icing on that cake.

If you’re interested in tracking progress, or chiming in with what else you would like to see implemented to streamline the Eclipse experience on Windows 7, refer to Eclipse bug 293226 and its subtasks.

Today’s releases of Tasktop Pro 1.6 and Eclipse Mylyn 3.3 represent a major step forward in the maturation of the task-focused interface. Mylyn has become the de facto framework for Application Lifecycle Management (ALM) integrations for Eclipse with an ecosystem that now includes 42 connectors. The Mylyn Connector Discovery mechanism that was released with Eclipse 3.5 Galileo makes it trivial to find and install connectors, helping users and encouraging the number of integrations to grow. The Tasktop Certified connector program has been a key enabler for enterprise adoption of Mylyn by ensuring the quality and compatibility of integrations that exist outside of the Eclipse Mylyn project. We are not done yet. But between the evolution of the framework, the size of the integration ecosystem, and the new features that we’re announcing today, I’m happy to say that support for task management has been established as the critical link between the ALM systems and the IDE.

The goal of the Mylyn project is to provide a task management framework and reference implementations for open source ALM technologies. Tasktop’s goal is to extend the reach of the productivity benefits of Mylyn to as many developers as possible, by integrating with commercial ALM systems and providing additional task-focused collaboration facilities. The very broad adoption of our technology is riding on the wave of the spread of Agile and Lean development processes, which make tasks a more explicit part of the development process. We have seen significant innovation around Agile ALM tool support from companies such as Atlassian, CollabNet, Danube, IBM, Microsoft, Rally and ThoughtWorks Studios. We’re continuing to see increasing usage of open source solutions like Bugzilla, Mantis and Trac. And with the input of broad enterprise adoptions of Tasktop Pro, such as Nokia’s, we have tailored this new task management layer of the IDE to make it easy for organizations adopting Agile to make the most of their ALM tools and get the dramatic productivity benefits of task-focused collaboration.

 
The Agile ALM Communication Disconnect

To realize the promised returns of an agile approach to development, developers must embrace the agile tool support they are using as their hub for communication and collaboration around code. However, developers can be resistant to adopting a tool that is not integrated with their working environment. Developers are all already experiencing a high level of overload, and agile tools introduce yet another inbox to track. The result is an anti-pattern of stories, subtasks and status being updated at the end of a sprint or release instead of as the changes happen. Or trying to figure out how much time was spent on a task two weeks ago when submitting timesheets.

This manual approach to ALM updates challenges the benefits of agile, because it results in ongoing friction for developers and a lack of useful visibility for product owners and management. Further developer frustration can occur when expectations that were assumed to be clear are not met. As developers, we want priorities to be clear and explicit and progress to be evident, since it makes it much easier to get things done, and to say “no” when yet another feature or enhancement is suggested. Managers need progress and priorities to be explicit in order to steer the product and features to meet users’ needs. To get the full benefits of agile, a new tool automation layer is needed to connect user stories and requirements at the project management level with the delivery happening at the developer level. We call this the “task management” layer of the agile development process.

 
Introducing the Agile Task Management Layer

This ALM communication disconnect is addressed by the agile task management layer in the development tool stack. The role of this layer is to organize work around tasks that represent actual development activity, automatically link related artifacts to tasks, and provide automation for updating ALM systems for real-time project visibility.

Within this layer, Mylyn provides the task management APIs that integrate the IDE with the various ALM systems in play. Tasktop and Mylyn connectors provide the integrations with a team’s tools for change management, source code configuration management, build and release management, and test and quality management. Tasktop 1.6 completes the layer by automating the linking and tracking of task across the very wide variety of commercial and open source ALM tools.

 
What’s new in Tasktop 1.6 and Mylyn 3.3?

Welcome Experience - Tasktop 1.6 includes a new welcome screen that introduces task-focused productivity features and settings step-by-step, making it easy to get started with the basics and then take advantage of Tasktop’s more advanced capabilities.

Task Federation – Teams with multiple ALM systems often find that tasks from one system depend on tasks in another. Tasktop 1.6 now supports linking across task repositories as well as importing and migration features, making it easy to manage tasks across ALM systems. For example, a user story in one system can be linked with defects in another.

Improved Time Tracking - New time charts and reports in Tasktop 1.6 take the pain out of time tracking by allowing developers to quickly review and adjust time spent on each task before submitting data to the team’s project management tools.

Full support for C/C++ – Mylyn 3.3 and Tasktop 1.6 now provide complete task-focused programming support is available for C/C++ developers using CDT. Code focusing was first implemented for Java, then extended to enterprise developers with focus for Spring Framework artifacts via the SpringSource Tool Suite, and as of this release is finally available to all developers using CDT.

In total, Mylyn 3.3 resolves 163 Bugzilla reports and includes 18 enhancements, see the Mylyn 3.3 New & Noteworthy. For more on Tasktop’s new capabilities, see the Tasktop 1.6 New & Noteworthy or download a free trial.

 
Close the ALM communication loop with Tasktop 1.6

Task federation, task context capture and to-the-minute time tracking mean that, as developers, we can easily indicate the task we are currently working, collaborate using the ALM tool instead of email, and convert a relevant email thread into a user story with a couple of clicks. Focusing and one-click multitasking across all ALM artifacts ensures that we activate tasks voluntarily, not because it was suggested that we do so. The privacy controls in the time tracking and context capture features streamline collaboration with management without loss of empowerment. And the fact that every task has a context associated with it provides long-term organization value, since it means that when we’re asked to fix a colleagues bug from six months ago, we get to start where they left off. By lining up project management’s needs for visibility with developer’s desire to deliver code without being overly encumbered by process, tool support for Agile task management takes the software development process to a new level of productivity and predictability.

Photo courtesy of seeb’s Photo Stream

In most development circles breaking the build is a serious offense, with good reason. As other programmers check out the broken source code their progress becomes blocked, as they can no longer compile (and thus test) the software. The cost of blocking an entire development team is so large that many shops have resorted to shame tactics, forcing offenders to wear embarrassing hats or shirts. Fortunately, Tasktop can significantly reduce your chances of obtaining a new headpiece by automatically tracking changes related to each task.

Common Problem: Committing Too Much, or Too Little
One of the major causes of build breakage is committing the wrong set of files for a given fix. These types of problems reduce to 1) committing files that are unrelated to the fix and 2) omitting files that are relevant to the fix. Either case can easily cause a broken build as a committed file can reference a new method or field in an uncommitted file. While it might sound easy to track the changed files for a particular task, developers that try to do this manually face several challenges:

1. Tracking individual tasks can exceed working memory – For some tasks developers must change more than a few files. For any task that requires changes to more than seven files the developer must remember a list of files that exceeds many people’s working memory capacity.
2. Multi-tasking requires multi-tracking – Developers work on more than one task in parallel, and thus must track files for each task. If a developer is working on five tasks in parallel, changing as few as three files per task requires remembering 15 files, in addition to the file to task mapping.
3. Tracking changes can span days, or even weeks – A particular development task can often become blocked after the developer has already changed several files. As the developer waits days or even weeks for the task to become unblocked his memory of the changed files will likely start to decay.

Tasktop can help you avoid these problems. It can automatically track the files you change for a given task, freeing up your working memory. Tasktop eliminates the multi-tasking problem as well, tracking changes for each task separately. Finally, it avoids the memory decay problem.

Solution: Automatic Change Set Management

In order to use Tasktop to automatically manage your change sets you only need to activate tasks as you work on them. To activate a task you can click on the icon next to the task in the Task List.

In this example Bug #59, “Cannot read emails from Thunderbird” has been activated, as indicated by the icon and the bold summary in the Task List.

Once you’ve activated a task continue to edit, compile, debug as you normally would. The only changes to your existing workflow are when you finish a task. Once you finish a task open the Synchronize View and toggle the model mode, as shown below:

Once the model is changed to show change sets you’ll notice that all of your outgoing changes have been arranged by task (i.e., a change set has been created for each task). Similarly, all incoming changes are organized by task. Below the same set of changes is presented in the Java Model Mode (background) and in Change Set Mode (foreground). Many people consider it much easier to interpret the changes in Change Set Mode because all of the changed projects and files for a given task are grouped together in that change set. In the Java Model Mode the changes are listed per project, and thus any changes involving more than one project are scattered throughout this list. Additionally, any project that contains changes for several tasks groups the changes together into one change set.

To commit your changes, select the current task, which is bold, and use the context menu to commit the changes. Tasktop automatically fills in your commit comment so that others know which task your changes correspond to, and can navigate from the committed code to the corresponding task.

In the above commit dialog the commit is for the task 5256 and the automatically generated comment includes the task status, task type, task ID, task summary, and, on the next line, the task URL. The format of the automatically generated comment is configurable, and you can change it to match the format that your team prefers (Window -> Preferences -> Task -> Team) by adding the completion date, the assignee, etc. or rearranging the order of the template. For this commit only one file is involved, the AbstractTaskAssociation.java file, which is shown below the commit comment.

Allowing Tasktop to manage your change-sets for you has several advantages. First and foremost, it ensures that you are committing the correct files for a given task. Although it is still possible to break the build* the chances of breaking the build are significantly reduced. Additionally, if you abandon a task prior to committing your changes for any reason, it is easy to revert the changes for that task by selecting “Override and Update” for that change set. Furthermore, all of your commits are automatically commented with a link to the relevant task, so others in the team can more easily interpret your changes. If all team members are using change sets to commit their code it can improve collaboration. For instance, a colleague can commit a fix and ask you to test it. Because the incoming changes are organized by change set you can select the fix of interest and just update that change, isolating the code of interest.

Tasktop’s change set management can reduce your mental burden during programming, allowing you to focus on the important problems at hand by tracking the details for you. If you’d like to get started with automatic change set management, download Tasktop Pro.

* If you work on two tasks in parallel that involve changing the same file it is possible to break the build by committing one of the tasks without committing the other.

As telecommuting and globally distributed teams become the status quo, face-to-face meetings are no longer the sole source of project updates. For many programmers, the issue tracker has become the most important source of information for their projects, yet monitoring an issue tracker can quickly become overwhelming. Gavin Sharp, a member of the Firefox team, reported receiving over 1800 email updates from his issue tracker in one day!

Gavin Sharp’s Bugmail Over Time: Gavin went as far as tracking his amount of overload vs time. Tasktop can save you from a similar fate.

While Gavin is likely an outlier, most developers can still receive dozens to hundreds of email updates per day. Without tool support for processing these updates, developers are overwhelmed by the volume of bugmail and hampered by their email client’s inability to present task updates in a structured manner. The Tasktop rich client eases this situation by reducing the number of updates, presenting recent changes in an easy-to-interpret manner, and focusing the user on important tasks.

Processing your initial incomings with Tasktop

When starting with Tasktop you’ll first need to connect to your issue tracker to enable you to access bugs or issues directly on your desktop. Given the myriad names for issues, bugs, etc., we use the term task to refer to an item of interest in your issue tracker and we use Task Repository to refer to the issue tracker itself. In a previous article (see: Tracking Tasks) we described how to set up Tasktop to track all tasks assigned to you and that you are interested in. Once you configure Tasktop you can begin systematically processing your incomings updates.

When you first connect to a Task Repository all your tracked tasks will be decorated in the Task List with a “new incoming” arrow (as on task #76 below), which means that you have not yet viewed it in Tasktop.

This icon and others, such as the “incoming” and “outgoing” arrows, allow you to quickly scan your Task List and determine which changes you should review immediately and which are less pressing (see UI Legend for a complete legend). This ability leads to Time Savings #1, illustrated below.

	Time Savings #1 – Processing tasks in a Task List is faster than processing tasks in an email inbox Which task would you view if you only had time to monitor one task? With the Task List, it’s easy to devote your attention to the most important issues because they’re categorized and prioritized. In the Task List above Task #3 has the highest priority, thus it is presented at the top of the list and the high priority icon is placed beside it. When all task updates appear as unreads in your inbox it is impossible to tell which update is most important.

As you work with Tasktop and see incomings you’ll notice that there are two ways of reviewing incoming updates. Some tasks you can review directly in the Task List using the tooltip preview. By hovering over a task with incomings you can view a summary of the changes to the task. For instance, the priority has changed from P2 to P1 on Task #10 below.

However, for other tasks, especially those tasks that you own, you’ll usually want to view the detailed changes, which is convenient in Tasktop. Click on the task in the Task List to open the Task Editor, which shows all of the task information and highlights the changed fields in light blue. Tasktop’s easy-to-scan UI leads to Time Savings #2, illustrated below.

Daily Processing with Tasktop

Once you’ve processed your Task List for the first time all future processing times will become much faster. Here are the top four tips for speeding up your processing time.

		Review Only the Blue – Many changes can be reviewed directly in the Task List, which is faster, but large updates require a detailed view. Double-click on a task to open the Task Editor for that task and review the changes, which are highlighted in blue. It does not take long to open the Task Editor (less than 200ms in almost all cases!) so do not hesitate to drill down on a task.
		Use the Tooltips - Hover over a task to see a summary of changes in a tooltip and avoid opening tasks where the incoming changes can be completely reviewed in the tooltip (e.g., a change in priority). If tooltip popup isn’t quick enough click on a task in the Task List and use the up and down arrows to scroll through the list with the popups showing.
		Mark as Read - Mark a task as “read” (i.e., removing the incoming arrow) by right clicking on it in the Task List and selecting “Mark as Read” or pressing Alt+Shft+R.
		Respond, Submit, Continue – If an incoming requires your response, open the Task Editor, update the task as necessary (e.g., add a comment), and submit. Then immediately continue processing your Task List. The Task Editor will inform you if the submit fails and you can continue to make progress during the submission.
		Reduce the noise - If you’re still getting too many incomings consider reducing the scope of your queries. A good rule of thumb is that if you don’t open the Task Editor for any tasks in a query during the course of several days then this query is not appropriate for day-to-day monitoring. Consider using working sets to hide these queries if you still want to monitor the tasks occasionally.

Tip number two, possible because Tasktop is a rich client, is an important time savings compared with many web UIs or email inbox and web UI combinations. Tasktop’s integrated approach which provides both a task view and the Task List in one window leads to Time Savings #3.

If you’re currently tracking your projects using email or even using your issue tracker’s web interface it is difficult (but not impossible) to follow a systematic workflow when processing tasks. Tasktop eliminates a lot of the accidental complexity of processing incomings and guides (without forcing) the user to become more systematic. We’ve found that systematic processing allows programmers to retain a better grasp on the state of his projects while at the same time reducing the time he spends tracking those projects. If you’re feeling overwhelmed by the volume of your project’s tasks and your task repository is already supported, check out the 60 day free trial of Tasktop and give us your feedback. If your repository is not yet supported make sure to vote.

The recent Mylyn 3.2 and Tasktop 1.5 release for Eclipse Galileo (3.5) includes a new Connector Discovery wizard that makes it much easier to find and install Mylyn and Tasktop connectors. This has proven to be a popular feature and we’ve teamed up with Atlassian to produce a short screencast that shows it in action.

This screencast shows an example of how to install the Atlassian Connector for Eclipse, which provides Eclipse integration for JIRA, Bamboo, Crucible and FishEye. All other Tasktop Certified connectors can also be installed using the Connector Discovery wizard.

For many developers, tracking time is an annoying but necessary part of their everyday life. Depending on the organization developers may be required to:

		Report the time spent on a particular project or for a particular client for the past month
		Report the actual time that it took to finish each task in the last iteration to refine Scrum estimations
		Report the average burn rate on a given contract for the past 6 months

Fortunately, Tasktop makes gathering and reporting this information painless. Tasktop not only tracks the time that you spend on each task (see Privacy below) it allows users to organize, adjust, and report this information to your team’s issue tracking system without leaving Tasktop or a Tasktop-enabled Eclipse IDE.

Managing Your Time with Tasktop

If you are already using Tasktop to organize your work then it is easy to set up Tasktop to manage your time as well. In fact, Tasktop is already tracking your time for your personal records and Tasktop’s Time Reporting Feature allows you to view and manage this information. To begin reporting your time with Tasktop you’ll first need to create a time report. On the time tracking dashboard (Tasktop Home -> Track Time) select “Create Report” and create a name for the report.

This report offers you detailed information about how you’ve spent your time in the task table as well as a graphical summary of your time data. The bar graphs at the top left show a breakdown of how you spent your time each day during the time period and the pie charts specify the time worked as a percentage, broken down into individual tasks and working sets. Take a minute to review how you’ve spent each day in the last week by hovering over individual cells in the bar graphs (as shown below). For a more detailed view of a given day select the “View by Day” button in the upper-right of the table section and the table will be reorganized to show the tasks worked on each day.

Once you have created a new report you’ll need to determine the scope of the report, in terms of time period and relevant tasks. For many users, these two guidelines will help them choose the best scope:

Because Tasktop automatically tracks your time and fills out your time report the only step that is left is to review this information. Since personal time information is private Tasktop gives you complete control over this information, including the ability to adjust automatically recorded times. When reviewing the report you can adjust it by:

		Adding/Removing tasks
		Adding/Removing offline activities
		Adjusting the time for existing tasks/activities

Finally, upon reviewing your time report you can submit it by pressing “Submit Time”. This will upload the times to your issue tracker for each task. A preview, as shown at the beginning of this post, will show exactly which tasks are being updated.

We recommend reviewing and submitting your time approximately each week, regardless of the time period of the report. This time period offers most people the best tradeoff between the overhead of opening the report and updating it and the potential of forgetting past offline activities, such as meetings, that they might need to add to the report. While we recommend a week, users can update and upload the reporter as many times as necessary, as only the updated data will be uploaded to the server.