This is an old revision of the document!
(More to come soon….Hopefully)
Now the Freestyler Bug Tracker (FsBT) is up running, people should post all found bugs here. It is easier for you and much easier for the developers.
To file a bug report you should do the following:
Write so many details as possible as this makes the developers job easier when they shall reproduce and fix the issue.
If you have any questions or have any issues with the bug tracker webpage feel free to email me on my email which is showed on the bug tracker bottom page.
If the report is not detailed enough and/or Developers can't reproduce the issue we will ask for feedback and more details via the bug tracker system.
the Bug tracker may change in layout and features as it is a new system and we are not finish configuring it.
An important part of issue tracking is to classify issues as per their status. Each team may decide to have a different set of categorization for the status of the issues, and hence, MantisBT provides the ability to customize the list of statuses. MantisBT assumes that an issue can be in one of three stages: opened, resolved and closed. Hence, the customized statuses list will be mapped to these three stages. For example, MantisBT comes out of the box with the following statuses: new, feedback, acknowledged, confirmed, assigned, resolved and closed. In this case “new” → “assigned” map to opened, “resolved” means resolved and “closed” means closed.
Following is the explanation of what the standard statuses that are shipped with MantisBT means.
This is the landing status for new issues. Issues stay in this status until they are assigned, acknowledged, confirmed or resolved. The next status can be “acknowledged”, “confirmed”, “assigned” or “resolved”.
This status is used by the development team to reflect their agreement to the suggested feature request. Or to agree with what the reporter is suggesting in an issue report, although they didn't yet attempt to reproduce what the reporter is referring to. The next status is typically “assigned” or “confirmed”.
This status is typically used by the development team to mention that they agree with what the reporter is suggesting in the issue and that they have confirmed and reproduced the issue. The next status is typically “assigned”.
This status is used to reflect that the issue has been assigned to one of the team members and that such team member is actively working on the issue. The next status is typically “resolved”.
This status is used to reflect that the issue has been resolved. An issue can be resolved with one of many resolutions (customizable). For example, an issue can be resolved as “fixed”, “duplicate”, “won't fix”, “no change required”, etc. If the issue is resolved as fixed it eill be released in next version and the next statuses is “closed” or in case of the issue being re-opened, then it would be “feedback”.
This status reflects that the issue is completely closed and no further actions are required on it. Typically it would be the reporter of the issue who close it to confirm the issue is fixed. It also typically hides the issue from the View Issues page.