Tasktop

We had another fun and informative Eclipse Demo Camp this past Wednesday here in Vancouver with over 50 participants braving the elements to attend. A number of attendees were participating in MOvember. These gentlemen could be easily identified by the presence of a moustache adorning their face (myself included). A number of the speakers were fellow “mo bros” and their donation pages are linked below where you can rate their moustache and make a donation.

What is Eclipse Demo Camp? The Eclipse Foundation sponsors Demo Camp events world wide. The Eclipse Demo Camp is a gathering of local Eclipse enthusiasts, giving individuals the opportunity to present or hear about Eclipse based technology being developed locally.

Vancouver Demo Camp Format. The Vancouver Eclipse Demo Camp has taken the “learn by fire hose” approach: 7 or 8 fast paced 10 min talks delivered by local industry and academics building on Eclipse. This includes a minute to answer a quick question while in parallel the next speaker is plugging in and lining up to deliver their talk. Its fast, its fun, and translates into rapid exposure to really cool technologies in just over an hour. Attendees have commented that this high energy, to the point format offers a nice alternative to events with longer talks.

The Speakers

We enjoyed talks from the following speakers:

Mik Kersten, lead of the Eclipse Mylyn Project and CEO of Tasktop, gave a quick introduction to the Eclipse Ecosystem and why it excels as a platform for innovation.

 
Andrew Eisenberg from SpringSource/VMWare demonstrated Groovy tooling within Eclipse and how easily Grails controllers and model classes can be generated from within the Spring Source Tool Suite. Slides (pdf)

 
Jim DeLaHunt of Jim DeLaHunt & Associates demonstrated how Eclipse can be used to perform runtime debugging of large php applications, something many of us take for granted. He equated life before discovering Eclipse PHP debugging to working with ‘bear skins and stone knives’ to get the job done. Great analogy Jim, I can’t imagine how I’d survive without Eclipse’s debugger.

 
David Green, a committer on the Eclipse Mylyn project, explained the problem of keeping documentation up to date and showed how Mylyn’s WikiText module can be leveraged to build Eclipse documentation crowdsourced from user contributed wiki content (i.e. from EclipsePedia). See David’s blog.  Slides (pdf) Movember Donations

 
Emerson Murphy-Hill from the Software Practices Lab at the University of British Columbia demonstrated a new way to communicate the presence of code smells through a visualizations called “stench blossoms”. These “blossoms” are drawn within the Eclipse editor along the right hand margin and scale in proportion to the severity of the smell. For more information, read the paper and download the tool.

 
Sam Davis from the Software Practices Lab at the University of British Columbia, demonstrated a prototype within Eclipse that dynamically presents the abstractions in your source code more succinctly (so that it feels like you’re using a dynamic language while in fact you’re still using java). You have to see it to believe it. If you would like to try this technology sign up for his user study.

 
Ian Bull from EclipseSource demonstrated the simplicity of customizing and provisioning Eclipse using Yoxos. In addition to custom Eclipse configurations, Ian also pointed out that Yoxos can help developers that need to manage multiple different instances/profiles of Eclipse. Movember Donations

 
David Shepherd from Tasktop closed the speaking protion of the evening off with a few quick best practices when working with Tasktop Pro. David put the call out to all Mylyn and Tasktop users to ping him on his twitter account and share your workflow practices. Slides (pdf), Movember Donations

After the presentations we all enjoyed good food, drinks and conversation. I’m already looking forward to the next Demo Camp! This is the third year Tasktop has organized this Eclipse community event, and each year has been better than the last. Thanks go out to Andrew Eisenberg from the SpringSource crew for helping with this year’s Demo Camp. Also, thanks to whoever provided the runtime debugging of my (paper based) sign up sheet at the event, catching my miss use of the assignment operator:

P.S. My Movember page. Drop me a donation and a comment!

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.

The recent upgrade of Eclipse.org’s Bugzilla to 3.4.1 has revealed a bug that can cause hundreds of false incomings in the Task List. Those users who are using Bugzilla 3.4.1 and have 1000+ tasks from that repository in their task list are likely affected by this bug.   A fix for this is now available in the most recent Mylyn weekly build. Update sites for weekly builds are available on the downloads page (under 3.3 Weekly Builds):

 http://eclipse.org/mylyn/downloads/#weekly

If you have already been affected by this bug and see hundreds of false incomings in your Task List, after installing the latest Mylyn weekly build you will want to restore your last known good task list using the Task List view menu’s “Restore Tasks from History…” wizard.

Tasktop Pro users, an Early Access build that includes the fix will be available before noon pacific time (Sept 1).  Once available the build will be announced on the EA announcement task.

If you are experiencing any problems submitting changes to existing tasks, try updating your repository configuration and then try submitting again. To force an update of the repository configuration, open the Task Repositories view (Window > Show View > Other > Tasks > Task Repositories), right+click on the repository in question and in the resulting popup choose “Update Repository Configuration”.

Applies to: Tasktop Pro or Eclipse Mylyn Level: Beginner Summary: Learn how to focus your Java programming efforts with Tasktop, increasing your personal productivity

Which files was I working with before lunch?

In the course of a day of programming developers often work on many tasks, where each task involves a different set of methods or files. This constant shifting between tasks causes two problems for the developer. First, when working on a particular task, the developer is often interacting with views that contain 90-99% irrelevant information*, causing him to constantly scroll and search.

Information Overload: All of the classes relevant to a task may not fit in the visible area of the PackageExplorer view. In the view to the left, only one of the two relevant classes (in green) shows without scrolling. The dotted line represents the bottom edge of the view; elements below this line are not visible.

Second, when switching back to a task previously worked on, the developer must recall the details of the previous task, including re-finding the relevant files, in order to restart work on the task.

Context Loss: Developers often forget which classes (files) were relevant when returning to an existing task.

Tasktop helps developers by reducing information overload and eliminating context loss. Developers can focus on the high-level problems, knowing that Tasktop is tracking the details for them.

Tasktop: Shows only relevant files during tasks and recalls files relevant to previous tasks.

Working Task-Focused

Working task-focused with Tasktop requires only a small adjustment to most developers’ workflow. Here we present an example workflow that developers may follow when working task-focused.

When working task-focused, a developer must activate a task before beginning programming for that task. This is the only required deviation from most developers’ normal workflow. To activate a task you can (A) press the “Activate” button in the task editor, (B) click on a task’s context icon in the Task List, or (C) use the recent task selector in the Task List.

Once you activate a task you will notice that the Package Explorer is now empty except for the phrase “Empty task context, alt-click or unfocus”. Your files are not missing. Tasktop has filtered your view to show only the files that are relevant for the task. Because you have not yet worked on this task, the set of relevant files is empty. There are several ways to find files and begin working on your task:

If the user chooses to start by using Open Type, and opens class X, class X becomes visible in the Package Explorer because the developer has expressed interest in it by viewing it. As a developer views and modifies this and other files, Tasktop automatically determines which files are most relevant, based on a degree-of-interest model (IBM Developerworks Article), and displays only those files to the user. The degree-of-interest model behaves as one might expect, marking files the developer views and modifies as relevant. However, as the number of files with which the developer has interacted grows, the view could become cluttered, so Tasktop systematically prunes and modifies the set of relevant files. For instance, files that the developer viewed only once will eventually drop out of view as the developer views and modifies other files. On the other hand, files that the developer modifies or views extensively will appear as bold in the Package Explorer, denoting their importance to the given task. The table below shows an example of developer activity and the corresponding elements that Tasktop would display as a result. Note that because class B was only viewed once, and never revisited, it has dropped out of view. In practice, it takes more activity to cause a file to drop out of view than the activity shown in the example.

Developer Activity	Files showing in Package Explorer
View class A View class B Modify class A View class C Modify class C Modify class A Modify class C View class A View class D

Working with the Package Explorer focused can feel like a major step for some developers. For developers that want to experiment with working focused without this step we recommend unfocusing the Package Explorer. Files that are viewed or modified many times during a given task will appear as bold in the Package Explorer, to indicate their unusually high importance to the task. When working with a task, notice how often that you return to the same few files. If you find yourself continually visiting the same set of files for a given task try focusing the Package Explorer. Tasktop will then focus you on that set of relevant files and eliminate extra scrolling and searching.

Multitasking

Tasktop helps you focus on completing individual tasks, but most developers spend their day moving between several tasks. Multitasking is where Tasktop really shines. Consider working on task A and populating your Package Explorer with relevant files. After working on this task for an hour you are interrupted by a high priority task B, which involves a different set of files. Upon finishing task B you return to task A. When you activate task A you will notice that the Package Explorer is populated with the exact same files as when you left the task. The diagram below illustrates the Package Explorer’s response to these task switches.

Repopulating the Package Explorer helps you restart your task with a minimum of searching and manual recollection. Often, developers will also put additional notes on the task itself, reminding them of the next step in completing the task, further reducing the cost of the context switch.

Managing Change Sets

Working task-focused with Tasktop has many additional advantages. For developers, one of the chief advantages is automatic change set management. As you work on a task and modify files Tasktop creates a change set for that task. Then, upon task completion, developers can submit exactly the files changed to address the given task, eliminating the need for manual tracking. Offloading this tracking allows the developer to work on more tasks in parallel, because she has confidence that there is a record of which changes go with which task. Managing change sets in this way virtually eliminates unintentional commits of unrelated files, which often cause problems in a source repository (e.g., compilation errors due to incomplete commits).

More Focus

Once you are comfortable working with the Package Explorer focused there are many other ways that Tasktop can focus your work. Here are a few highlights for you to explore:

Focus your assist menus: Tasktop will place relevant elements at the top of content assist and Open Type selection menus.

Focus your source code editor: Tasktop can be set to fold all elements that are not relevant in your source code editor.

Focus across all views: Tasktop focuses many other code views, such as the outline view, providing the same focus consistently throughout the IDE.

Working Task-Focused

Currently most code views in Eclipse are ineffective… they show too many files or elements to be usable. Tasktop reclaims these views by limiting their scope to the current task and the relevant files. Task-focused code views reduce clicking and scrolling during individual tasks and ease the transition between two tasks by serving as the programmer’s memory of relevant files. Tasktop tracks the details of programming tasks so you can focus on being more productive.

*This estimate was calculated using the author’s workspace and the author’s average number of relevant files.

Tasks are a vehicle for communication. Tasks that you create may be completed by others, and next month you might resume tasks that you create today. Whether communicating with others or with your future self, your style of communication will affect its clarity. A task you create named do the coding, while possibly meaningful when you created it, will not be clear in three weeks when you resume it. To assist you in creating tasks with style, we present the following guidelines and tips. These guidelines improve communication while also improving more technical task qualities such as searchability. If you have other naming patterns that you are using, please consider commenting on this post, as we are always iterating on these guidelines based on our understanding of task usage.

Naming tasks

Naming tasks is a surprisingly important step in task creation, as it affects a variety of task qualities. A carefully named task is straightforward to search for and, once found, easy to begin or resume work on because it is easy to understand. Follow these guidelines to create well-named tasks:

1. Start with a verb, follow with the object(s): Most task names naturally consist of a verb and one or more objects (nouns). If you consistently order these components of the task name then it is easier to scan each name, to search task names, and to categorize tasks.

   Example: add_verb content assist_object for tasks_{object 2}

2. Be specific: Using specific verbs and nouns when formulating a new task name will make this task easier to search for at a later time and will make the purpose of an older task easier to recall. In addition, being specific when naming tasks makes it easy for collaborators to understand your task.

   Example:	addverb open report buttonobject for timesheets pageobject 2
   Anti-Pattern:	makeverb buttonobject for pageobject 2

We provide two types of examples to make our guidelines more concrete. First we provide a list of verbs that commonly appear in task names. Note that many verbs are domain specific and so the most commonly used verbs will differ depending on your domain.

We also provide examples of complete task names that follow the above guidelines:

Anti-patterns when naming tasks

In addition to these guidelines we have also indentified the following anti-patterns. These anti-patterns, derived from the guidelines, address common mistakes that are made when naming tasks.

1. Avoid ambiguous references: During the act of naming tasks it often feels like overkill to precisely name all objects involved, and you will be tempted to create tasks like update wizard icons on the page. While it is clear at the time which page you are referring to, by the time you are able to work on that task it will require thought to recall, at best wasting time, at worst creating an incorrect product.
2. Avoid adverbs: Avoid starting task names with adverbs like “quickly” or “carefully”, since they are often related to planning or priority information and not to the goal of the task.
3. Avoid names and dates: Tasks are decomposed into separate fields, such as “Due Date” or “Assigned To”, so that tasks can be presented according to their properties. For instance, tasks with overdue deadlines can be shown as red. Do not include information that belongs in other task fields in the name, including collaborator names, due dates, and project names. The task named implement refresh with Todd will become inconsistent if you change your CC field to include John instead of Todd.
4. Omit common verbs: Bug reports are traditionally named with a summary of a problem. For example, tasks losing scheduled date after restart. In this sense, all defect reports are implicitly prefixed with some variant of a verb like “fix”. Since the verb could be the same for all bugs, there is not much value in adding it.

Following all of these guidelines and tips when naming tasks will lead to increased output that both yourself and your collaborators will appreciate. While it can be difficult to appreciate these guidelines in the abstract, concrete tasks that break these guidelines serve as an enlightening illustration. Here’s an example that breaks the guidelines and tips for naming tasks:

Scoping tasks

Other providers of task management systems (e.g., CollabNet, 43 Folders) agree that tasks should be reasonably sized, usually defined in terms of the estimated time to complete a task. These providers recommend avoiding tasks that are too small (e.g., type a method header), because you will spend too much time tracking every detail, or too large (e.g., implement the product), because you are likely to become overwhelmed or lost. We avoid more precise scoping rules because we have found that following our task naming guidelines, especially “be specific”, naturally leads to well-scoped tasks.

Describing tasks

Although naming a task is the most important aspect of creating a task, there are several other task fields that can be completed during task creation. Here we provide a table with recommended content for several important fields:

Giving tasks a good home

When using Tasktop, you can choose to either create local tasks (on your machine only) or shared tasks (on a server, shared with others). If you are the only person involved in the entire lifecycle of a task, create a local task. If any collaboration is involved, e.g., input from others, the task forms a part of a product release cycle, it should be a shared task. Don’t worry if you’re not sure at task creation time where your task should live as it is easy to move between local and shared tasks using Tasktop’s “Send To” action in the Task List.

When using shared tasks collaboration is simple; you can add collaborators to a task and track task communication on the task comment thread. Collaborators can use a variety of repositories so Tasktop offers several Tasktop Certified Connectors (i.e., that connect Tasktop to the repository). To begin sharing tasks browse and download Tasktop Certified Connectors.

During the course of a project you and your team could create hundreds or even thousands of tasks. If your team follows these task creation guidelines you will save time searching for old tasks, remembering the goal of an existing task, and interpreting a task someone else has assigned to you. You and your team will understand the benefits of working with your task management system, instead of against it, as you begin creating tasks with style.

UPDATED on January 30, 2009: We’ve revised the best practice to simplify the configuration and avoid duplicate tasks in the task list. We will address more advanced configurations in an upcoming how-to.

Tracking Changes with Tasktop

When working in a team tasks change quickly. The team lead raises the priority of your task, a co-worker indicates your task is blocking his work, or a domain expert responds to your task-related question. Keeping up with these changes, while still making progress on your tasks, can be overwhelming. Fortunately, Tasktop can help reduce this burden by automatically tracking relevant tasks with Queries. A Query specifies the tasks that are relevant to you, such as tasks you are in charge of completing. Creating a Query downloads and periodically updates tasks directly in your Task List, eliminating the need for checking email updates or refreshing web interfaces. These advantages and others make Queries an important part of Tasktop users’ workflow.

Screenshot 1: Is your email inbox cluttered by task updates?

In this article we’ll walk you through the mechanics of setting up a single Query as well as introduce best practices on creating a set of Queries that monitors all relevant tasks.

Mechanics: Creating a Query

Creating a Query in Tasktop is simple assuming one prerequisite. You must first configure a Task Repository (see previous post), which, fortunately, is a straightforward task. Assuming you’ve configured a repository, follow these steps to create a query:

1. Right click on the Task List and select “New Query” (see Screenshot 2)
2. In the resulting dialog select the appropriate Task Repository
3. Fill out the Query creation form and press “Finish” (see Screenshot 3 for Bugzilla’s form)

Screenshot 2: Creating a new Query

While this form includes many options to empower the advanced user, simple queries are easy to create and beginners can leave most fields blank. See the “Best Practices” section below for example form values that create common Queries.

Screenshot 3: Bugzilla’s Query creation form is shown. Other repositories, such as JIRA, have a similar query form.

Task Synchronization
Once created, Queries automatically download relevant tasks and periodically synchronize with the task repository, ensuring that your Task List is always up-to-date. You can adjust the automatic synchronization interval by navigating to Window -> Preferences -> Tasks. You can also manually synchronize by right-clicking on a task or query and clicking “Synchronize”. When updating, a Query or Task will be displayed in italics in the Task List (see Screenshot 4).

Screenshot 4: Task 3778 (in italics) is being synchronized and Task 3817 has already finished.

Once a Task or Query is updated Tasktop will create visual indicators in the Task List (see Screenshot 5). In the example below Tasks 2 and 11 have changed since they were last viewed and Task 15 is a new task has not yet been viewed. A single scan allows you to know which tasks are updated, which are new, all within the context of your Task List, which is sorted by priority and scheduled date. When using the Task List to stay updated you can eliminate task update emails. As a final step to eliminate these emails we recommend turning off email notifications on your Task Repository (see “Turning Email Updates Off” below).

Screenshot 5: A Task List with notifications: arrows indicate updates and arrows with ?s indicate new tasks.

Best Practices: Crafting a Smart Set of Queries
Tasktop allows significant configurability when deciding which queries to put in your Task List. To achieve the full benefit, we recommend you try the following guidelines when setting up your Task List. Do this for every task repository of interest.

1. Set up a single query for all tasks assigned to you.
2. Set up another query for all tasks that you’ve reported, commented on, or been CC’d on.

If you follow these guidelines you will end up with a Task List that is similar to this one:

This query set focuses you on the tasks you own (“All Mine”) while keeping you in the loop on the tasks where your input is needed (“All Related”). To setup these queries, use the following parameters in the Bugzilla query form.

In some cases, it’s also desirable to create queries to easily track the tasks of people you collaborate with closely. We will address this more advanced case in an upcoming how-to.

Now that your Task List is populated you are better prepared to deal with a busy workweek. New tasks may be assigned to you and priorities may change but your Queries will keep you up-to-date. You’ll be able to focus on the task at hand, knowing that you’ve offloaded significant responsibility to Tasktop.