Tuleap: move artifacts between Trackers

This is a feature that is often asked in Tuleap Trackers. It recently got some traction as Wayne Beaton from Eclipse Foundation pointed out as one of the few things that could prevent a migration from venerable Bugzilla to Tuleap.

 

First, why this feature doesn’t exist in the powerful Tuleap Trackers yet ?

 

Because it’s hard !

 

When coming from tools like Bugzilla or Redmine it sounds an easy and basic operation to do. But Tuleap Trackers are really different. We don’t have one single “issue” (or bug, artifact, you name it) list that is re-used across projects. In Tuleap, each tracker can (and often) has a different structure from another. While Project Alpha decides to have a dedicated select box to track whether the bug is assigned to a West-Coast or East-Coast support team, Project Gamma decides to add “Overall satisfaction rating” radio buttons.

 

Each tracker is different, that’s one of the key strengths of Tuleap.

 

But in this case it’s also a weakness. As you can imagine, it’s tricky to decide what to do when we want to copy an issue from Project Alpha to Project Gamma.

 

Moving vs duplicating

We can state that, by moving an artifact from one Tracker to another it’s likely that some data might be lost. We hate to lose data, in Tuleap world traceability is a key. If an information was submitted by an end user, there is no reason to loose this information because some triage re-direct the bug to a less defined tracker structure.

 

So we propose an alternative with a smart duplication. The first draft of epic is available on tuleap.net, contributions and feedback are welcomed.

 

To summarize the approach:

  • When an artifact is moved from one tracker to another, end user will see
    • The original artifact frozen (read-only) where they submitted it.
    • An explicit information telling them that it was moved in another project / tracker (with a link to it).
    • In destination artifact, all informations that were movable are there with a reference to original submission so one can refer to it.
  • On Move, we are going to copy as much informations as we can based on duck-typing: for all fields in the source artifact, if there is a field with the same name and same type in the destination tracker, we assume it’s the same value.

Prototyping

Code is better than talk. We want to quickly measure if what we propose is acceptable so we decided to do a first, limited, implementation of what we propose. As we are doing it the Agile way, we want to test end-to-end with a limited set of features.

 

6a00d8341ca4d953ef01a511e114a3970c

The first stories covers:

How I can help ?

In so many ways, it’s insane, you can:

  • review the epic and tell us what you like and what you would suggest as improvement
  • CC yourself to one of the stories and propose to test when it’s ready
  • reach developers on the mailing-list to help them for implementation
  • subscribe to Enalean’s OpenRoadmap to crowd-fund the feature

About the Author

Write Your Comment

14 + 3 =

You may use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>