Bugtracker: Difference between revisions
(added new page about Shareaza bugtracker. Corrections supporting proper English are welcome ;-)) |
No edit summary |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{Language}} | |||
A '''BugTacker''' is a software which allows to control and manage reported bugs and feature requests, which it is essential for organizing development work and preventing "reported but forgotten bugs". Reports/problems/feature requests are described in so called tickets which are managed like records in a database. In fact the BugTracker is the database of tickets for continuous development purposes, joining, structuring and prioritizing efforts of beta testers, developers and common users. | |||
Before you | Before you use our BugTracer (called {{trac|report|Trac}}) to report a problem, you should read about [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively]. This is important as it makes solving the reported problems much more easy and less work for out devs. You will save lots of nerves and time, yours and ours. Very recommended to make life and development easier and more happy. | ||
Before you | Before you create a new ticket with a problem description for the first time, first check also out how other tickets have been written. It will help you to find out the used convention, which implies from practice. Also, you should check whether there is already an existing tickets where anybody else has already reported the same problem as you are experiencing. In this case, you ought to add your confirmation, description, as well as additional info to this ticket as a new comment, so our developers get more detailed info about the problem gathered in one place. Many tickets about the same case are not helping, but disturbing as the probability of accidental omitting important information is increasing. | ||
In general | In general reports in BugTracker tickets should be as informative, precise, short and easy to understand as possible. Otherwise they are often just useless. Efforts to improve Shareaza can be only as successful as the quality of the bug reports. Please have this in mind, because we are an Open Source project and your mistakes in reports can kill your efforts and potentially useful ideas - give them a chance by writing good reports please. | ||
Currently, we use {{trac|report|Trac}} as our BugTracker system, which is well integrated with SourceForge resources and the source repositories. This is why it is preferred by coding developers, but many users have problems with the integrated Trac Wiki interface, that's why we are using [[Main Page|MediaWiki]] (this Wiki) for help and support, while using Trac to submit bugs. | |||
On our recently lost project domain, [http://shareaza.trillinux.org/bts/ Flyspray] (currently not officially used) was used as BugTracker and feature request tracker. After Will Ervin has devastated this and we lost the domain, not only the content of the old Wiki has been lost, but also most of the content of that BugTacker was lost and when migrating our project pages to SourceForge.net in 2009, {{trac|report|Trac}} has become the official BugTracker of our project. | |||
[[Category:External Links]] | |||
Latest revision as of 17:19, 1 March 2010
 Languages: |
[[::Bugtracker|English]] • [[::Bugtracker/de|Deutsch]] • [[::Bugtracker/es|Español]] • [[::Bugtracker/fr|Français]] • [[::Bugtracker/he|עברית]] • [[::Bugtracker/it|Italiano]] • [[::Bugtracker/nl|Nederlands]] • [[::Bugtracker/pl|Polski]] • [[::Bugtracker/pt|Português]] • [[::Bugtracker/ru|Русский]] • [[::Bugtracker/zh-hant|中文(繁體)]] | e |
A BugTacker is a software which allows to control and manage reported bugs and feature requests, which it is essential for organizing development work and preventing "reported but forgotten bugs". Reports/problems/feature requests are described in so called tickets which are managed like records in a database. In fact the BugTracker is the database of tickets for continuous development purposes, joining, structuring and prioritizing efforts of beta testers, developers and common users.
Before you use our BugTracer (called 
Trac) to report a problem, you should read about How to Report Bugs Effectively. This is important as it makes solving the reported problems much more easy and less work for out devs. You will save lots of nerves and time, yours and ours. Very recommended to make life and development easier and more happy.
Before you create a new ticket with a problem description for the first time, first check also out how other tickets have been written. It will help you to find out the used convention, which implies from practice. Also, you should check whether there is already an existing tickets where anybody else has already reported the same problem as you are experiencing. In this case, you ought to add your confirmation, description, as well as additional info to this ticket as a new comment, so our developers get more detailed info about the problem gathered in one place. Many tickets about the same case are not helping, but disturbing as the probability of accidental omitting important information is increasing.
In general reports in BugTracker tickets should be as informative, precise, short and easy to understand as possible. Otherwise they are often just useless. Efforts to improve Shareaza can be only as successful as the quality of the bug reports. Please have this in mind, because we are an Open Source project and your mistakes in reports can kill your efforts and potentially useful ideas - give them a chance by writing good reports please.
Currently, we use Trac as our BugTracker system, which is well integrated with SourceForge resources and the source repositories. This is why it is preferred by coding developers, but many users have problems with the integrated Trac Wiki interface, that's why we are using MediaWiki (this Wiki) for help and support, while using Trac to submit bugs.
On our recently lost project domain, Flyspray (currently not officially used) was used as BugTracker and feature request tracker. After Will Ervin has devastated this and we lost the domain, not only the content of the old Wiki has been lost, but also most of the content of that BugTacker was lost and when migrating our project pages to SourceForge.net in 2009, Trac has become the official BugTracker of our project.