Laboratoire ICAR » Plateforme TXM

h1. Tickets Creation

{{>toc}}

General principles are described in the txm-info wiki: https://groupes.renater.fr/wiki/txm-info/public/transition_wiki_tickets

h2. Ticket template

h3. Feature and Task tickets

**title**

Pattern: "Command name, a small description sentence"

e.g.: Concordance, add a super parameter to manage lines

e.g.: Add a new super cool window dark theme

**description**

<pre>

Description of the objective and the context.

Link to the wiki specification page (if available).

h3. Solution

Steps and means to implement the ticket.

h3. Validation Test

Procedure to follow to validate the implementation of the ticket.

* action 1

* action 2

* action 3

</pre>

h3. Bug and Support ticket

**title**

Pattern: "[Command name,] Version, OS, a small description of the problem"

e.g.: Concordance, 0.8.0, Linux, everything is written in wrong direction

e.g.: 0.7.9, Windows/Mac OS X, everything is wrong

**description**

<pre>

Context and origin of the bug description (mail, TXM version, OS, etc.)

h3. Steps to reproduce

* step 1

* step 3

h3. Diagnostic 1

* Hypothesis

* Observation

* Conclusion

** the bug is reproduced

** the bug is not reproduced by this hypothesis

h3. Diagnostic 2

* Hypothesis

* Observation

* Conclusion

** the bug is reproduced

** the bug is not reproduced by this hypothesis

h3. Solution

Steps and means to resolve the ticket.

h3. Validation Test

Procedure to follow to validate the resolution of the ticket.

* action 1

* action 2

* action 3

</pre>

h2. Ticket categories definitions

Available ticket categories:

* Administration: portal administration interface and tools (Portal project)

* Charts: charts plotting issues

* Charts / R port from JFC: missing functionalities needed to be implemented in R charts engine from JFC charts engine and low priority issues since the default charts engine is now JFC

* Commands: any command related issue (all projects)

* Conventions:  algorithms and terminology conventions (all projects)

* Development: development tasks, installation and configuration of TXM development environment, RCP projects management, source code structure, etc.

* Documentation: any documentation issue (manuals, wikis, web pages...) (SH: Javadoc?)

* Import: any import module issue

* Network: network communication (despite of the component or layer, e.g. R, RCP, etc.)

* Preferences: RCP preferences issues

* Setup: desktop RCP setup issues

* Stats: statistic models issues

** Stats / R: R related statistic models issues

* Toolbox: any issue related to the Toolbox project

* UI: User Interface issues in the RCP project (SH: and GWT project?)

** UI / Interaction: user interface behavior issues

** UI / Link / Command: user interface hypertextual command behavior issues

h2. Ticket hierarchy policy

There are 2 usages:

* Grouping tasks

* Phasing tasks: children are steps and are ordered

h2. Ticket life cycle

Instructions for alpha testers:

* for a given release

* do the 'validation test' section of each ticket marked as 'Feedback'

* if the validation test cannot be passed, set the ticket percentage between 0-79 as an estimation of the remaining work to be done

* set the ticket to 'Resolved' state when the validation test is passed

Ticket status+percent follow this cycle:

* Developement cycle

** "New" + 0: the ticket is *not* being handled by the developer

** "InProgress" + 1-79: the ticket is being handled by the developer

** "InProgress" + 80: the ticket has been implemented and is *NOT* yet ready to be tested

* Alpha cycle

** "Feedback" + 80: the ticket has been implemented and is proposed to be tested by testers

** "Feedback" + 0-79: the ticket has been downgraded by the alpha tester from the 80 status

** "Resolved" + 90: the ticket has been validated by alpha testers

* Release cycle

** "Closed" + 100: the ticket has been validated on production portal or by beta testers= the ticket is closed

Warning: parent tickets don't follow that policy (percent is computed)

h2. Ticket and complexity evaluation

Use the "Estimated time/Temps estimé" field as a *resolution complexity rate* field. The rate value starts from 0 (easy|quick) to 100 (very complex|long).

h2. Ticket and documentation

If a ticket may impact the documentation: 

* add a line such as : "DOC: fix section x.x.x"

* set category to "Documentation"

h1. Complementary txm-info wiki specification page

If a txm-info wiki page is created to describe in more details information related to a ticket, the description must contain a direct link to that page. Use the *@page_name* syntax to refer to the page.

txm-info wiki specification page pattern : 

<pre>

====== Titre du développement (nom du composant, etc.) ======

Canevas de la spécification d'un développement.

===== Objectif =====

Description de l'objectif du développement.

===== Méthode =====

Description de la méthode de travail pour atteindre l'objectif.

==== État de la plateforme ====

Avancement dans l'élaboration de la solution.

===== Solution =====

Description de la solution choisie ou des solutions à choisir.

==== État de l'art ====

Éléments de solution.

==== Prototypes ====

Premières réalisations concrètes de la solution.

=== Alpha ou Étape 1 ===

=== Beta ou Étape 2 ===

==== Version finale ====

===== Documentation =====

Si possible, développer la documentation en même temps que la solution.

==== Utilisateur ====

==== Développeur ====

===== Recette =====

Tutoriel décrivant explicitement étape par étape l'usage concret de la solution pour valider sa conformité par rapport aux objectifs.

=== Alpha ou Étape 1 ===

=== Beta ou Étape 2 ===

etc.

</pre>