Document Actions
How to fill in a bug report on bugtracking?
Tickets are created when somebody detects a bug or a feature request about the application. For this purpose it is needed to fill in the form. The first thing to do is to create a ticket in the bugtracking, you can di it from this link Create a ticket.
Ticket`s fields
Tickets are composed by these fields:
Short summary. Short description of the ticket explained in only one line.
It doesn´t have to tell about the version nor the build number in which the error has been detected. It must be concise to identify the problem in a clear form.
Type. You can create 3 types of possible tickets: bug, feature request or user documentation bug.
It is really important to set this value correctly in order to treat the ticket correctly.
Full description. The full description of the bug, as clear as possible. The reporter has to describe the problem or sugestion step by step till the error is encountered.
Ticket Properties
Priority. All tickets must be created with the priority set to major. If the reporter think the ticket has to set to a major priority, it must be justified by a comment explaining the reasons.
Version. Version number of the project in which the bug or feature is detected. Nowadays the possible projects are: gvSIG Desktop or gvSIG Mobile.
The version number can be found on the About window of gvSIG.
Assign to. User name to whom the ticket is assigned.
The reporter of the ticket will NOT assign it to any developer.
Visibility. All tickets must be created with the visibility set to Publico.
Subproject version. This field will only be set if the ticket is related to an error or feature request found in a gvSIG extension installed independently on the project (gvSIG desktop or gvSIG Mobile). It will be set with the number of the version of the extension installed.
This information could be found on the About window of the application, on the tab of the extension.
Build number. Build number of the Project (gvSIG Desktop o gvSIG Mobile).This information could be found on the About window of the application.
Resolve version. This information must NOT be filled in by the reporter of the ticket. This field is set by the developer that fix this error or feature request. The resolve version refers to the subproject version in which the reported bug has been fixed.
Component. The components refer to the extensions that are included in the subproject selected. If this information is not known by the reporter, please select Sin Determinar.
Keywords. Keywords could be included in order to search by them in later queries.
CC. This field is used to send copy of the ticket's life notification. In order to include users to it, you might enter its user names separated by commas.
Revised. This field will only be changed in the stabilization stage, once the verification of the ticket occurs. If this field is checked, it is understood that the bug reported on it is fixed.
Subproject build number. This field will only be set if the ticket is related to an error or feature request found in a gvSIG extension installed independently on the project (gvSIG desktop or gvSIG Mobile). It will be set with the build number of the extension installed.
This information could be found on the About window of the application, on the tab of the extension.
Project. Main project where the error or feature request is detected. Nowadays the possible projects are gvSIG Desktop o gvSIG Mobile.
Subproject. This field must be always filled in. When the ticket refers to a gvSIG extension, this is the value that must be selected. Otherwise, the selected value must be gvSIG.
Resolve build number. This information must NOT be filled in by the reporter of the ticket. This field is set by the developer that fix this error or feature request. The resolve build number refers to the subproject in which the reported bug has been fixed.
Some considerations when reporting a ticket
Before starting the report it is necessary to investigate if there is no other ticket already created which expresses the same bug or feature request. This can be done by searching some keywords in this link: Bugtracking search
Before starting the report it is also necessary to collect all the information that is needed.
Attached files:
Application log. Whenever the reporter has the possibility, the log of the apllication will be attached. Where is the log file? Find it
Screenshots. The reporter can add additional information through screenshots that complements the verbal description.
It is possible to attach the data used in the test, and also all the information that will need to clarify the problem itself.
When you are introducing the description or come comments of the bug, you have to bear in mind that TRAC uses a specific format for its texts. It is possible to look up the format's description at this link . It can be used the reStructured Text format, that is the same as in Plone, or plain text.
