wiki:UtilisationTickets_English Back to the Wiki Welcome page.

Tickets user guide

The various requests for enhancements and corrections to the draft Ancestris are made using tickets managed on this site. This page is intended to define how these applications can be made by users and how these tickets are managed by Development Team .

TODO put a few reports here (eg all active tickets)

For users

First as an unauthenticated visitor, you can only view existing ticket. If you are interested in creating or supplementing tickets, simply send an email to François to request access to the site.

Basic information of a ticket

Tickets include a number of fields that must be filled with as much precision as possible for them to be taken into account in the best conditions. The purpose of this guide is to give some tips for writing these informations. The fields are as follows:

Provide here a description as precise and concise as possible to know immediately what is going on. This information will be used in all the pages giving an overview summary of the project progress.
The nature of the ticket (defect, enhancement, task)
Full description with all information necessary for its consideration
The module or the part concerned by the ticket
The version used
Ticket impact on the project.
The importance or priority of this ticket granted by the developer or development team. Do not be confused with the severity! The range is very Low to very High. Note: This field is set by the development team.
Etape or deadline for this ticket. Note: This field is set by the development team.
Other (s) user (s) interested in the progress of this ticket
Assign to
Developer in charge of the ticket. Note: This field is set by the development team.


The type of the ticket can be:

for a malfunction found
for an application addition or improvement of function.
any other action that does not fall into one of the two previous categories and does not require modification in the code of Ancestris or in its documentation


The description of the ticket is the most important part. It must contain all relevant information so that the developer can understand and possibly reproduce the problem. These informations are essential for the application to be processed efficiently.

In case of a malfunction, it is useful to specify:

  • The comprehensive approach to reproduce the problem. Feel free to attach a file if necessary but beware! This file is readable by everyone, so no confidential information.
  • Informations on the system used:
    • Machine type
    • OS
    • Java version
  • ...


Module covered by the ticket (Report, help, ...).


Not used yet, to fill in the description of the ticket


Allows you to sort the tickets. Note: This field is set by the development team.


Blocking point. Without resolution of this ticket, the project can move forward. It is only used in exceptional situations and only for malfunction.
Serious dysfunction, serious crash of the application or module that can lead to data loss, total lock of the application or system. Can also only be used for tickets of type default.
Significant loss of functionality without easy alternative. This encompasses both the faults and enhancement requests. The defect does not lead to data loss (put Critical in this case).
The majority of defects or request to enhancements.
Minor problem or need. Or a simple alternative exists without canceling the interest of the request.

Developer Guide


The importance or priority of this ticket granted by the developer or development team. Do not be confused with the severity! The range is from very Low to very High. The award criteria of priority can be discussed within the development team but the meaning will always be to give more importance to developments in which the ticket has the highest priority. This does not necessarily means that this ticket will be resolved before other of lower priority because other criteria may be considered.
For example, we can use the following criterias

  • Very High: Contributes directly to our ambition, high demand, no alternative
  • High: Contributes directly to our ambition, high demand and there is an alternative
  • Normal: Contributes directly to our ambition, not in high demand and no alternative
  • Low: Contributes directly to our ambition, not in high demand and there is an alternative
  • Very Low: Do not contribute directly to our ambition

Status (State)

New Ticket awaiting acceptance.
ticket accepted. This is the second stage in the life of a ticket. This means that the problem has been reproduced or the function deserves some attention here. In other words, the ticket is deemed valid by the team Ancestris.
ticket assigned to a developer ... a solution will be found soon ;-)
the problem or the improvement is solved. See below the different cases of possible closure
Ticket closed can be reopened if the problem persists. Attention think carefully before re-opening a ticket ...

Resolution (Résolution)

the ticket is closed because the correction or improvement has been made to the code. Or in the case of a task, it has been done.
false issue or enhancement request already exists.
the problem is not directly related to Ancestris or the requested function is not achieved because the development team does not consider that it is a part of the project objectives
created ticket does not concern the project
there is already a ticket on the same problem.
  • When you close a duplicate ticket, it should be indicated in the two tickets. For example:
    • in duplicate: This ticket is a duplicate of #1234
    • in the original ticket: Ticket #4567 has been marked as a duplicate of this ticket
  • Always let the ticket containing the most relevant information open.


A description of a ticket can be amended only by the development team in very specific cases. Each time that this description is changed, the original text should be retained and additional information clearly identified. This can be:

  • format error correction without affecting the original
  • Information on the progress of a development that can be long
  • any notes deemed important and useful so that it does not drown in the thread of discussion

Milestone (Jalons)

Milestones roughly correspond to different versions planned for the project. The following rules shall apply:

  • If the resolution is fixed the milestone must be positioned in line with the development plan (Roadmap)
  • If the resolution is wontfix , invalid or worksforme the milestone must be left blank.
  • In the case of an improvement or an addition of function, do not record as a milestone release that corresponds only to corrections of malfunctions.
  • If the requested function is a relatively long-term vision, use 99.0
  • If the ticket appears to be corrected within a reasonable time but is not a part of the development plan, we will then use the landmark corresponding to the next major version in the course of development. At the time of writing this leaflet (September 2009) version under development is the version 1.0 We will use the version 2.0
  • When no milestone correspond but the ticket is still valid, use En attente.

Keywords (Mots clé)

The role of keywords is to provide to the tickets an information in view to then find them simply by using specific query. For the moment the allowed keywords are:

  • needinfo - Waiting for information from the user
  • verify - The ticket appears to be valid but the development team has not been able to check (different system, java version, ...). In this case a support is sought from a willingness person to reproduce the problem.
  • tobedeleted - Tickets to be removed (mainly tickets that have nothing to do with the project).
  • helpwanted - A developer is sought for this ticket :-)
Last modified 7 years ago Last modified on Mar 1, 2014, 9:07:40 AM