How to approach solving a bug/Feature/Task (developers)
-----------------------------------------------------------

Before starting
------------------

When a developer is going to face the resolution of a bug, the first thing to do is **to assign it to himself** (if it had not been already assigned) and then **accept it**. This way other developers will be informed that *there's someone working  on  the subject*. 

Remember that on the *stable branch* or during the *stabilization period* approaching the resolution of a Ticket **should not be faced** **without knowledge / consent of the responsible / coordinator of testing**. 

The bug will then pass to *assigned* (state of a ticket) and the developer will be able to start solving the problem. 

Communication 
----------------

If during this process the developer needs to communicate with the tester or someone else,  he has to add, on the *CC* field, the users / addresses of those who need to be informed and write the comment in the ticket itself.

Communications between tester and developer should take place through the comments of the Ticket so that everything is monitored. If there were other communication, it should be reflected afterwards on the ticket, at least just a summary. 

Within the ticket comments anyone can refer to another ticket using the following format: 

::

   {abr_trac}:#{numero_ticket}

Where: 

+ **abr_trac** :*Optional*, required only if the ticket is from another trac. Trac Abbreviation where the ticket is published. Usually *Bugtracking* **bug** or **core** for *gvSIG Core*. For other Tracs please ask.

+ **numero_ticket** :Reference Ticket number. 


Upload changes
-----------------

When the developer needs to make changes on a project on which he has no permissions, in order to accomplish the task, He has to attach a *patch* to the ticket and reassign it to a developer who has permission to do so. 

When you upload any changes to the repository, in the **commit commentary** should be included a reference to the task that caused it. This should be done with the following format:


::
  
  {comentarios del cambio}

  {abr_trac}:#{numero_ticket}

Where: 

+ **abr_trac** : Trac Abbreviation where the ticket is published. Usually *Bugtracking* **bug** or **core** for *gvSIG Core*. For other Tracs please ask.

+ **numero_ticket** : Reference Ticket number. 


This way the changes will be *linked* to the ticket. By uploading these changes, the SVN generates some *change numbers* or *changeset* that identify the modifications uploaded to the repository. These *changeset*, to maintain the *link*, should be **noted in the comments of the ticket** with the following format: 


::
  
  {Comentarios}

  SVN {Rama} [gvsig {numero_changeset}] [gvsig {numero_changeset2}] ...

Where:

+ **Branch** : SVN Branch where changes were made. Normally **trunk** or **branches/v10**.
 
+ **numero_changeset** : Change identifying number in the repository. This number is displayed on the *SVN console* when doing the *commit* otherwise you can find it with *Team / Show resoerce history* of modified files.

    * Note*: To facilitate the monitoring it is *advisable* to try to *group commits* whenever it is posible. 

Close the task
--------------------

If the bug is solved, the developer has to set it as *fixed* and fill the fields *resolve version* and *resolve build number*. This data can either be found by looking at the page *stage test* of the version (the next to the last one generated) or, in case of doubt, asking the person responsible for packaging or distribution.


**Under no circumstances** the tester should change the value of the fields *version* or *build number*. 

If the bug can not be fixed the developer will set the resolution to *wontfix* and leave the fiels *resolve version* and *resolve build number* blank

If the bug is duplicate this must be set on  the field *resolution* and in the comments include a reference to the ticket where it was resolved. To refer to another ticket see the `Communication`_ section of this page. 

Every time you fix a bug, or perform any important task that is going to be included in a gvSIG bug, the developer, in addition to updating the corresponding ticket, should add to the page *test phase* of the affected product  the link to the ticket in the appropiate version / build, the link title will be the same as the ticket, or a note that reflects the job he has done.  This way, testers can adequately validate the work done. This action must be performed for  each of the tickets / bugs corrected.