Wiki
Version 35 (Matthieu Decorde, 29/10/2014 15:49) → Version 36/65 (Serge Heiden, 05/11/2014 11:51)
h1. TXM forge principles and procedures
h2. Tickets Creation
General principles are described in the txm-info wiki: https://groupes.renater.fr/wiki/txm-info/public/transition_wiki_tickets
h3. 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>
h3. Ticket template
h4. 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>
h4. 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>
h3. Ticket categories definitions
Available ticket categories:
* Development : development tasks
* Administration: portal administration interface and tools (Portal project)
* 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
* 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
h3. Ticket hierarchy policy
There are 2 usages:
* Grouping tasks
* Phasing tasks: children are steps and are ordered
h3. Ticket life cycle
Ticket status follow this cycle:
New -> In Progress -> Resolved -> Feedback -> Closed
* +New:+ the ticket concerns a demand not yet handled
* +In Progress:+ the demand is currently being handled
* +Resolved:+ : the solution is developed
* +Feedback:+ tested during the *Alpha step* by the other users and developers.
* +Closed:+ the solution is approved and is deployed throughout *Beta Step*.
Other status that can occur at any time in the development:
* +Rejected:+ the demand is not to be handled
Ticket percent follow this cycle:
* 0-79: the ticket is being handled by the developer or has been downgraded by the tester from the 80 status
* 80: the ticket has been implemented and is proposed to be tested by someone else
* 90: the ticket has been validated on "test" portal
* 100: the ticket has been validated on production portal = the ticket is closed
Warning: parent tickets don't follow that policy (percent is computed)
h3. Ticket and documentation
If a ticket may impact the documentation, add a line such as :
DOC: fix section x.x.x
h2. Sourceforge SVN Usage
h3. 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
h3. 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]]
h2. Tickets Creation
General principles are described in the txm-info wiki: https://groupes.renater.fr/wiki/txm-info/public/transition_wiki_tickets
h3. 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>
h3. Ticket template
h4. 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>
h4. 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>
h3. Ticket categories definitions
Available ticket categories:
* Development : development tasks
* Administration: portal administration interface and tools (Portal project)
* 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
* 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
h3. Ticket hierarchy policy
There are 2 usages:
* Grouping tasks
* Phasing tasks: children are steps and are ordered
h3. Ticket life cycle
Ticket status follow this cycle:
New -> In Progress -> Resolved -> Feedback -> Closed
* +New:+ the ticket concerns a demand not yet handled
* +In Progress:+ the demand is currently being handled
* +Resolved:+ : the solution is developed
* +Feedback:+ tested during the *Alpha step* by the other users and developers.
* +Closed:+ the solution is approved and is deployed throughout *Beta Step*.
Other status that can occur at any time in the development:
* +Rejected:+ the demand is not to be handled
Ticket percent follow this cycle:
* 0-79: the ticket is being handled by the developer or has been downgraded by the tester from the 80 status
* 80: the ticket has been implemented and is proposed to be tested by someone else
* 90: the ticket has been validated on "test" portal
* 100: the ticket has been validated on production portal = the ticket is closed
Warning: parent tickets don't follow that policy (percent is computed)
h3. Ticket and documentation
If a ticket may impact the documentation, add a line such as :
DOC: fix section x.x.x
h2. Sourceforge SVN Usage
h3. 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
h3. 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]]