Laboratoire ICAR » Plateforme TXM

*TXM FORGE PRINCIPLES AND PROCEDURES*

{{>toc}}

h1. Tickets Creation

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

h2. Ticket description and txm-info wiki page complementary description

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

Squelette de page : 

<pre>

====== Titre ======

===== Objectif =====

===== 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 =====

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

Éléments de solution

==== Prototypes ====

==== Version finale ====

===== Documentation =====

==== Utilisateur ====

==== Développeur ====

===== Recette =====

==== Protocole de test ====

=== Alpha ===

=== Beta ===

==== État courant ====

Qui Quand Quoi

</pre>

h2. Ticket template

h3. Feature ticket

<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

<pre>

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

h3. Diagnostic

h4. Diagnostic 1

* Hypothesis

* Observation

* Conclusion

** the bug is reproduced

** the bug is not reproduced by this hypothesis

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:

* Development : development tasks

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

* Charts: charts plotting issues

* Commands: any command related issue (all projects)

* Conventions:  algorithms and terminology conventions (all projects)

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

* Import: any import module issue

* Match R charts engine with 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

* 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

Ticket status+percent follow this 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

* "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 tester from the 80 status

* (GOTO InProgress+80)

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

* "Closed" + 100: the ticket has been validated on production portal = 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. Sourceforge SVN Usage

h2. SVN folders structure

* copyright: contains copyright files

* corpora: contains  samples binary corpus (deprecated)

* CWB: contains modified CWB sources (fix error logs, jni code)

* doc: contains all kind of TXM documentation

* groovy-all: contains a RCP dependency project to enable Groovy scripting in TXM

* Eclipse : contains the modified Eclipse project (p2 and workbench)

* installers : contains a linux environment to build TXM for all supported architectures (Debian, Windows and Mac OS X)

* libs: contains dependency projects (mandatory ones) of the TBX (and RCP ?) (groovy-all should be moved here)

* plugins: contains plugins for TXM (optional ones)

* RCP: contains the TXM RCP project

* sdk: contains environment to build TXM SDK

* textometry: contains the "textometry" R package sources

* Toolbox: contains the Toolbox main dependency of the RCP project

* translation: contains tools to translate TXM manual

* WEB: contains TXM portal sources

h2. SVN commit messages

*content*

Each commit message must follow the syntax :

* prefix with *SOMETHING: *(space char)

* then insert the nature of the commit for example : *add*, *fix*...

* then insert the message content and details

* if you need more than one line to describe the entry, prefix the following lines with "#"

*Prefixes*

Prefixes are :

* *RCP:*  the TXM desktop (RCP) project

* *TBX:*  the Toolbox (TBX) project

* *WEB:*  the TXM portal project

* *DOC:*  the documentation of any project

* *SETUP:* the project that contains scripts to build TXM setups

* *EXT-<PLUGINNAME>:*  The extensions of TXM

* *LIB-<TECHNOLOGY>:*  Third party library plugins used by the TBX or the RCP

** *LIB-GROOVY:*  the Groovy-all plugin

** *LIB-JFC:*  the JFreeChart plugin

* *R-<package>:* R Packages

** *R-textometry:* the 'textometry' package sources

* *PLUGIN-<PLUGINNAME>:*  _obsolete_ (See EXT-<PLUGINNAME>)

* *GROOVYALL:* _obsolete_ (See LIB-GROOVY)

* *SETUPS:* _obsolete_ (See SETUP)

* *LIBS:*  _obsolete_ (See LIB-<TECHNOLOGY>)

*Example*

<pre>

TBX: add an awesome new functionnality

TBX: fix the XXX import module

# the flow was not Groovy enough

# end of this entry

DOC: add documentation of the new functionnality

</pre>

For further details about commit message syntax, follow those principles:

https://github.com/erlang/otp/wiki/Writing-good-commit-messages

h1. Related projects

# [[TXM for Oriflamms]]