Mylyn/UCOSP 2015 Project

Introduction

Code review tools have increasingly become an integral part of the development process. In some cases, code review systems are used as a substitute for an issue tracker like Bugzilla or JIRA, but usually, both are used together to take advantage of the richer feature set provided by issue trackers. In that case, most reviews will be associated with an issue by including an issue ID or URL in the commit message. An issue may have multiple reviews associated with it.

The Mylyn Reviews project has integrated Gerrit code reviews into Mylyn by treating them as tasks. Thus, each review appears in the task list and has a task context, scheduled date, private notes, time tracking data (task activity), comments stream, and so on. If an issue tracker such as Bugzilla or JIRA is also used, the associated issue also appears in the task list and has its own task context, scheduled date, etc. which are distinct from those of the associated reviews.

Problem

Mylyn performs two key functions which can be hindered by treating code reviews as tasks.

Aggregation of Information

The first key function of Mylyn is that the task editor allows users to aggregate all information associated with a task in one place, including their personal notes and the task context that is automatically gathered while they work on the task.

Treating code reviews as tasks works well when no issue tracker is used. It can also make sense for workflows where code reviews are treated as sub-tasks of the associated issue. But it has created significant problems for a common workflow where code reviews are more naturally seen as artifacts produced during a development task, rather than as separate tasks themselves. In this case, treating each review as a task creates duplication in the task list and duplication of task context and scheduling. This is confusing and discourages best-practice use of Mylyn. Furthermore, the task list doesn't show any association between the issue and the code review, and the task editor does not provide a way to see and navigate to the reviews associated with a task.

Consider the following typical scenario. A developer starts working on an issue, activating the corresponding task in her task list. At some point she produces a code review which then appears as a second task in her task list. Conceptually, there is only one task , but the task list contains two entries for it. At this point, it doesn't make sense for her to activate or schedule the review because the original task already has a task context and scheduled date. Activating the Gerrit review instead of the issue also has the disadvantage that there is no way for the context to be shared with other developers because Gerrit does not support attachments.

Change Notification

The second key function of Mylyn is change notification. The task list and task editor replace event-based change notification with a status indicator and a way to see all changes since the last time the user looked at a task. Thus, events are batched so that the user can consume all new events for a task at once, instead of receiving an email notification from an issue tracker every time any issue changes.

While the Gerrit connector benefits from Mylyn's notification mechanism, it also pollutes the notifications with a lot of noise, because Gerrit events (e.g. patch set created, build started, build finished) occur much more frequently and have much lower relevance on average, as compared with events in an issue tracker. Additionally, all events in Gerrit appear as "comments" with no way to distinguish them without reading the comment stream. So Gerrit is actually using the comments as an activity stream, and you end up with event-based notification in the task editor comments section. It's not easy to see the current status, or what has changed since you last looked at the review; you must read through the comment stream to make sense of it.

Solution

The situation can be improved for all workflows by supporting a tight integration between issues and code reviews, and we can better support the workflow where code reviews are mostly not treated as separate tasks by allowing users to explicitly choose their workflow when configuring a connection to a Gerrit repository. The following are the major changes needed. These are intended to work together in support of these goals, but each would be useful on its own. The images below are just mock-ups intended to show roughly what the solution might look like.

1) Make the status of builds apparent by showing the builds associated with each patch set next to that patch set instead of as a series of events in the Gerrit comment stream. Hide non-comments such as build notifications from the comment stream.

2) Add a Reviews section to the task editor which shows the status of all associated reviews, including a summary of incoming changes. E.g. "Review 123 has 1 new patch set, 2 successful builds, and 1 comment."

3) When a review has incoming changes and it's associated with a task in the user's task list, provide an indicator on the associated task that there are incoming review changes.

4) Add an option to the Gerrit repository settings to select the default workflow for that repository. If a review has an associated task in the user's task list and the user has selected a workflow where such reviews are not treated as tasks, filter the review from the task list (do not show it unless the user is using the task list search box). Also remove task context and scheduling affordances, and 3rd party contributed task editor sections, from the review editor for these reviews.

5) Provide an affordance for converting a code review to/from a task (i.e. to choose whether it shows up in the task list and has its own task context and so on).

Plan

A detailed plan is available at Mylyn/UCOSP_2015_Plan.