Functional overview

Why do we do that ?

The goal is to address a tracability / auditability issue. When something is happing on a project (good or bad) it's hard to tell why it's happening. We can observe that a burndown doesn't go down or a burn-up stay alarmfully flat but why ?

Tuleap Baseline aims to give an insight of what changed between 2 points in the time.

Let say you have a 6 month long project. At T0 you did an handshake and all stakeholders agreed around a Budget+Feature+Time perimeter. 1 month (T1) later you do the project review and the team annonce they will need 1 more month  to complete the project. Stakeholders are not happy but if you are able to show them that 3 more requirements/stories/bugs were added in between and that the main story acceptance criteria were rewritten at 80%, the discussion will be easier to drive.

In Tuleap Baseline, T0 and T1 are 2 snapshots (or baselines) and what you observe between the 2 snapshots is a "Diff" (we should find a better term, maybe snapdiff).

In one line: Tuleap Baseline will save your a** during your next customer / steering meeting ;)

Behaviour

Perimeter of v1

The first version of Tuleap Baseline will

• be based on artifacts only. Later versions will support other objects will be included in the BL like document versions, deliverys, code, etc).
• leverage the release definition we have in Agile Dashboard Scrum. Later version will allow to select any kind of artifact and to select how their relative artifacts (links) are consumed.

Set a baseline/snapshot

It's possible to set a baseline from the Planning (and maybe from the Artifact view of the Release artifact).

When a baseline is set, it's attached to a "changeset" of an artifact (think of follow-up comments) as well as all changesets of the linked artifacts following the Planning definition. Only the "Backlog" is taken into account (for instance for agile project epic, stories, bugs). The milestones (sprints, sub-releases, etc) are excluded of the snapshot (otherwise it will polluate the output).

Once set the baselines are visible in the artifact history (follow-up comments) next to the follow-up comment when the baseline was set.

Observe a baseline

A baseline can be observed. It means that you can get a textual representation of all the artifact like a document.

# Release 1.0

Status: On going
Start date: 2019-01-01
Duration: 120
Scope: ... some text ...

## Implement some stuff

Title: Implement some stuff
Status: Todo
Estimated effort: 30
...

The stucture of the document (titles) is given by the level of depth in artifact tree and the fields that are displayed (and in which order) are selected in the "Baseline" configuration. This configuration is done tracker per tracker.

This HTML document can be exported in PDF.

Compare two baselines

The same way you can observe a baseline, you select 2 of them (related to the same release) and obtain a diff between the 2 (as a diff).

# Release 1.0

Status: no change
Start date: no change
Duration: 120 -> 150
Scope: no change

## Implement some stuff and some other stuff

Title: Implement some stuff -> Implement some stuff and some other stuff
Status: no change
Estimated effort: 30 -> 50
...

Note: the exact format to be really usable is yet to be precised. Do we need to base the diff on the "Observe" configuration (what about fields that changed outside that scope) ? Do we need to display fields that didn't change ? If yes, how to we display that (either "no change" or use colors or use of strike ...).

It's possible to "persist" the diff. It becomes then an "object" with and ID, an URL and a cross ref. This way we can make a reference to this diff if we change things in the scope of project (eg. "Remove some acceptance criteria after review of diff #...").

Known issues / Questions

• Currently attachments are permanently deleted. This can cause issue if we want to retrieve artifact at a given changeset.
• How does a diff behave on a user selectbox if a user was selected and became suspended?
• Should it be a plugin (plugins/baseline, plugins/baseline_trackers, …) or part of the core?
• Reverse links are not snapshotted in the artifact (eg: fixed_in in request/release trackers)