Changes between Version 3 and Version 4 of UtilisationTickets_English


Ignore:
Timestamp:
Jun 16, 2010, 6:41:27 AM (8 years ago)
Author:
fm
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • UtilisationTickets_English

    v3 v4  
    44[[PageOutline]] 
    55 
    6 Need to be done 
     6 
     7= Tickets user guide = 
     8 
     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 . 
     10 
     11'''TODO''' put a few reports here (eg all active tickets) 
     12 
     13== For users == 
     14 
     15First as an unauthenticated visitor, you can only view existing ticket. If you are interested in creating or supplementing tickets, simply [http://www.arvernes.com/wiki/index.php/Utilisateur:Fm#Mon_adresse_Mail send an email to François] to request access to the site. 
     16 
     17=== Basic information of a ticket === 
     18 
     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: 
     20 
     21'''Summary 
     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. 
     30Milestone 
     31    Etape or deadline for this ticket. Note: This field is set by the development team. 
     32Cc 
     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. 
     36 
     37Type 
     38 
     39The type of the ticket can be: 
     40 
     41malfunction 
     42    for a malfunction found 
     43improvement 
     44    for an application addition or improvement of function. 
     45task 
     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 
     47 
     48Description 
     49 
     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. 
     51 
     52In case of a malfunction, it is useful to specify: 
     53 
     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    * ...  
     60 
     61Component 
     62 
     63Module covered by the ticket (Report, help, ...). 
     64Version 
     65 
     66Not used yet, to fill in the description of the ticket 
     67Keywords 
     68 
     69Allows you to sort the tickets. Note: This field is set by the development team. 
     70Severities 
     71 
     72Blocking 
     73    Blocking point. Without resolution of this ticket, the project can move forward. It is only used in exceptional situations and only for malfunction. 
     74Critical 
     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. 
     76Major 
     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). 
     78Normal 
     79    The majority of defects or request to enhancements. 
     80Minor 
     81    Minor problem or need. Or a simple alternative exists without canceling the interest of the request. 
     82 
     83Developer Guide 
     84Priority 
     85 
     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 
     88 
     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 
     94 
     95Status (State) 
     96 
     97new 
     98    New Ticket awaiting acceptance. 
     99accepted 
     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? . 
     101assigned 
     102    ticket assigned to a developer ... a solution will be found soon ;-) 
     103closed 
     104    the problem or the improvement is solved. See below the different cases of possible closure 
     105reopenned 
     106    Ticket closed can be reopened if the problem persists. Attention think carefully before re-opening a ticket ... 
     107 
     108Resolution (Résolution) 
     109 
     110fixed 
     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. 
     112worksforme 
     113    false issue or enhancement request already exists. 
     114wontfix 
     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 
     116invalid 
     117    created ticket does not concern the project 
     118duplicate 
     119    there is already a ticket on the same problem. 
     120 
     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. 
     125 
     126Description 
     127 
     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: 
     129 
     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 
     133 
     134Milestone (Jalons) 
     135 
     136Milestones roughly correspond to different versions planned for the project. The following rules shall apply: 
     137 
     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 . 
     144 
     145Keywords (Mots clé) 
     146 
     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: 
     148 
     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 :-)