Tickets Creation
Version 4 (Serge Heiden, 11/29/2016 09:59 am) → Version 5/7 (Matthieu Decorde, 01/31/2020 04:40 pm)
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 ticket
**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.
*Step 1*
*Step 2*
*Step 3*
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.) etc.).
h3. Steps to reproduce Diagnostic
* step 1
* step 3
h3. h4. Diagnostic 1
* Hypothesis
* Observation
* Conclusion
** the bug is reproduced
** the bug is not reproduced by this hypothesis
h3. h4. Diagnostic 2
* Hypothesis
* Observation
* Conclusion
** the bug is reproduced
** the bug is not reproduced by this hypothesis
h3. Solution / Resolution
Steps and means to resolve the ticket.
*Step 1*
*Step 2*
*Step 3*
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 documentation
If a ticket may impact the documentation, add a line such as :
DOC: fix section x.x.x
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>
{{>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 ticket
**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.
*Step 1*
*Step 2*
*Step 3*
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.) etc.).
h3. Steps to reproduce Diagnostic
* step 1
* step 3
h3. h4. Diagnostic 1
* Hypothesis
* Observation
* Conclusion
** the bug is reproduced
** the bug is not reproduced by this hypothesis
h3. h4. Diagnostic 2
* Hypothesis
* Observation
* Conclusion
** the bug is reproduced
** the bug is not reproduced by this hypothesis
h3. Solution / Resolution
Steps and means to resolve the ticket.
*Step 1*
*Step 2*
*Step 3*
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 documentation
If a ticket may impact the documentation, add a line such as :
DOC: fix section x.x.x
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>