Changes between Version 3 and Version 4 of UtilisationTickets_English

Jun 16, 2010, 6:41:27 AM (8 years ago)



  • UtilisationTickets_English

    v3 v4  
    6 Need to be done 
     7= Tickets user guide = 
     9The 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 . 
     11'''TODO''' put a few reports here (eg all active tickets) 
     13== For users == 
     15First 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. 
     17=== Basic information of a ticket === 
     19Tickets 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: 
     22    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. 
     23'''Type''' :: The nature of the ticket (defect, enhancement, task) 
     24'''Description''' :: Full description with all information necessary for its consideration 
     25'''Component''' :: The module or the part concerned by the ticket 
     26'''Version''' :: The version used 
     27'''Keywords''' :: Keywords 
     28'''Severity''' :: Ticket impact on the project. 
     29'''Priority''' :: 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. 
     31    Etape or deadline for this ticket. Note: This field is set by the development team. 
     33    other (s) user (s) interested in the progress of this ticket 
     34Assign to 
     35    Developer in charge of the ticket. Note: This field is set by the development team. 
     39The type of the ticket can be: 
     42    for a malfunction found 
     44    for an application addition or improvement of function. 
     46    any other action that does not fall into one of the two previous categories and does not require modification in the code of Genji or in its documentation 
     50The 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. 
     52In case of a malfunction, it is useful to specify: 
     54    * 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. 
     55    * Informations on the system used: 
     56          o Machine type 
     57          o OS 
     58          o Java version 
     59    * ...  
     63Module covered by the ticket (Report, help, ...). 
     66Not used yet, to fill in the description of the ticket 
     69Allows you to sort the tickets. Note: This field is set by the development team. 
     73    Blocking point. Without resolution of this ticket, the project can move forward. It is only used in exceptional situations and only for malfunction. 
     75    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. 
     77    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). 
     79    The majority of defects or request to enhancements. 
     81    Minor problem or need. Or a simple alternative exists without canceling the interest of the request. 
     83Developer Guide 
     86The importance or priority of this ticket granted by the developer or development team. Do not be confused with the severity! The range is Low to 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. 
     87For example, we can use the following criterias 
     89    * Very High : Contributes directly to our ambition, high demand, no alternative 
     90    * High : Contributes directly to our ambition, high demand and there is an alternative 
     91    * Normal : Contributes directly to our ambition, not in high demand and no alternative 
     92    * Low : Contributes directly to our ambition, not in high demand and there is an alternative 
     93    * Very Low : Do not contribute directly to our ambition 
     95Status (State) 
     98    New Ticket awaiting acceptance. 
     100    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 GenjFr? . 
     102    ticket assigned to a developer ... a solution will be found soon ;-) 
     104    the problem or the improvement is solved. See below the different cases of possible closure 
     106    Ticket closed can be reopened if the problem persists. Attention think carefully before re-opening a ticket ... 
     108Resolution (Résolution) 
     111    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. 
     113    false issue or enhancement request already exists. 
     115    the problem is not directly related to Genji or the requested function is not achieved because the development team does not consider that it is a part of the project objectives 
     117    created ticket does not concern the project 
     119    there is already a ticket on the same problem. 
     121        * When you close a duplicate ticket, it should be indicated in the two tickets. For example: 
     122              o in duplicate: This ticket is a duplicate of # 1234 
     123              o in the original ticket: Ticket # 4567 has been marked as a duplicate of this ticket  
     124        * Always let the ticket containing the most relevant information open. 
     128A 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: 
     130    * format error correction without affecting the original 
     131    * Information on the progress of a development that can be long 
     132    * any notes deemed important and useful so that it does not drown in the thread of discussion 
     134Milestone (Jalons) 
     136Milestones roughly correspond to different versions planned for the project. The following rules shall apply: 
     138    * If the resolution is fixed the milestone must be positioned in line with the development plan (Roadmap) 
     139    * If the resolution is WONTFIX , invalid or worksforme the milestone must be left blank. 
     140    * 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. 
     141    * If the requested function is a relatively long-term vision, use 99.0 
     142    * 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 
     143    * When no milestone correspond but the ticket is still valid, use Pending . 
     145Keywords (Mots clé) 
     147The 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: 
     149    * needinfo - Waiting for information from the user 
     150    * 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. 
     151    * tobedeleted - Tickets to be removed (mainly tickets that have nothing to do with the project). 
     152    * help wanted - A developer is sought for this ticket :-)