Our submission to the NIER (New Ideas and Emerging Results) track at ICSE 2010 has been accepted!
In this paper, Peggy and I explore the idea that the use of tags in task management systems could lead to the introduction of new task categories. This research was prompted by the observation that the software development team in one of our Jazz case studies used tags such as linux and windows to indicate that a particular task was specific to an operating system. During the replication of our study a year later, we observed that the team didn’t use these tags anymore, instead the category Operating System had been made a field in every task.
Looking at this phenomenon in more detail, we found that there were other instances: Tags such as testing and selfhosting had been replaced by a How Found category, and tags such as eclipse, firefox and ie had been replaced by a Client category.
Based on these preliminary insights, we pose the following research questions:
RQ How can tagging play a role in bridging lightweight task management and heavyweight task management?
- What role do tags play in the adoption of new task categories?
- How can data on the use of tags help determine the right balance between lightweight and heavyweight task organization?
- How is software developers’ use of tags for task organization different from the tag use of users outside of software development?
We have focused on the first sub question for the NIER paper, but the positive comments from our reviewers encouraged us to keep working on this research. Looking beyond Jazz, a very interesting case is given by the way labels are implemented in Google Code (see: http://code.google.com/p/support/wiki/IssueTracker#Labels). Their concept of labels is similar to social tagging in other task management systems. However, the Google Code issue tracker goes beyond basic labels to support key-value labels. Key-value labels contain one or more dashes, and the part before the first dash is considered to be a field name while the part after that dash is considered to be the value. For each project, a list of predefined labels and their meaning can be specified. Studying how developers make use of this approach is on top of our to-do list.
This is the preliminary abstract of our NIER paper:
In collaborative software development projects, tasks are often used as a mechanism to coordinate and track shared development work. Modern development environments provide explicit support for task management where tasks are typically organized and managed through predefined categories. Although there have been many studies that analyze data available from task management systems, there has been relatively little work on the design of task management tools. In this paper we explore how tagging with freely assigned keywords provides developers with a lightweight mechanism to further categorize and annotate development tasks. We investigate how tags that are frequently used over a long period of time reveal the need for additional predefined categories of keywords in task management tool support. Finally, we suggest future work to explore how integrated lightweight tool features in a development environment may improve software development practices.
Update [June 6, 2010]: The paper is now available here (ACM Digital Library).
Christoph Treude 
Congratulations Christoph! I look forward to reading your paper.
Did the Jazz developers choose which categories to have at the start, or were these predefined somehow? It seems to me that exploring how their categories originally came about, and how did they resolve to formalize the use of a tag into a new category, are key events for these phenomena.
Thanks Jorge!
One of the main differences between tags and task categories is that the task categories are the same for all developers (at least mostly, you can choose to hide some for specified roles), whereas developers can choose their tags freely. In the end, turning tags into task categories is a decision made by the person on top of the hierarchy, usually the development manager. The way I see it is that this kind of decision is not really collaborative (at least in our case studies so far), but the decision is based on the tags that emerged.
To start with, they probably copied the task categories from other projects such as Eclipse. In the original task categories, I didn’t see anything that was unexpected.
I had never really thought about the different task categories until we started this research (severity, priority, planned for, etc.). Based on our initial literature search, it seems as if there isn’t much work on this. Given the important role that development tasks play in most software development processes, it seems really interesting though to see how exactly these tasks are managed, and to investigate why they are managed a certain way. An interesting paper that I came across is this one http://portal.acm.org/citation.cfm?id=1370750.1370786, but that’s just a first step.