# Introduction

Software development is almost useless without testing, and that's true for Scribus as well, of course. Testing means using the software, especially development versions. Bugs, when discovered, need to be reported to let the developers know that something's wrong or at least seems to be wrong, so the problem can be fixed, if necessary. Sometimes the fix may simply be an update to the online documentation, the wiki or the next edition of the Official Manual. Moreover, the developers need to know what kind of features users need. In such a case case, someone who is missing a feature or has a great idea, should also let the team know about it.

In both cases, the procedure is the same. There is a software called bug tracking system, in Scribus' case this is Mantis. A bug tracking system allows developers to keep track of, discuss and review bug reports and RFEs (requests for enhancement). If you want to help to improve Scribus or absolutely need a feature, you are advised to use it.

# How to Create an Account

First, visit the signup page. You will see a page that looks like this:

Enter a login name, your email address and the digits displayed. Then click Signup and wait until your account has been confirmed and you received a password. You can change your personal preferences any time in the tab "My account," provided you are logged in. Please take the time to check the different options. They may or may not be useful to you.

# Before filing a bug

If something doesn't work as expected or you think you have the idea of the century, please don't start firing up bug reports galore. Chances are that someone has already had the same problem, perhaps even the same great idea. Five steps are recommended to ensure your report won't be closed as "duplicate" or "no change required".

1. Read the Scribus documentation, rummage the Scribus wiki or even consider buying the Official Scribus Manual. There are lots of informations in different languages available, and perhaps someone has already turned his own experiences into a wiki article, or the documentation team may have documented a feature/issue thoroughly by then.
2. Try to really use Scribus and learn about its concepts. Compared to other DTP programs, Scribus is not hard to learn, but it is still quite different from, say, a word processor.
3. Tell one of the mailing lists about your problem or your idea. Things normally get sorted out quickly. Often enough, a supposed bug is just lack of experience.
4. Ask questions on IRC. This is especially useful for "real time" support.
5. If your questions still haven't been answered, you should browse the bug database. You can search for keywords. As you can see on the screenshot below, you can enter a keyword in the "Search" field. Then click Apply, and Mantis will search for all reports containing the text string. If you don't know the correct English word to search for, you can skim the multilingual Glossary on the Wiki for a translation. If you use a non-English version of Scribus and want to look up the English names of menu items, just switch the Scribus interface to English: File > Preferences > General > Language

You will notice that the reports are coloured differently. The meaning of the different colours is:

new | feedback | acknowledged | confirmed | assigned | resolved | closed

- New: The bug/RFE is reported, and no decision has been made as to how to handle it.
- Feedback: Feedback is required from either the original reporter or someone who added a note to the report. This happens quite often in cases where an issue can't be reproduced.
- Acknowledged: Once the team has decided a suggestion is worth keeping in mind for further development, the status is changed to "acknowledged." This is mostly the case with RFEs.
- Confirmed: If a reported bug could be reproduced by others, the status will change to "confirmed." This is what usually happens to bug reports.
- Assigned: A bug or RFE is assigned to a developer for fixing it or adding a feature.
- Resolved: A bug or RFE is resolved. That doesn't necessarily mean a developer wrote any code. If things cannot or need not be fixed, the issue will be resolved as well.
- Closed: The end of a life span of a report. If all works well, the issue will finally be closed, and the scary number of reports/requests is a bit smaller.

# How to file a bug report

To file a bug report, you have to click on the Report Issue link in your browser. You will be presented a page with lots of fields for entries:

- Categories: Choose a category you think your report fits best. If you can't find an appropriate category, choose "General."
- Reproducibility: If you report a bug, can you reproduce it? How often does it happen? Choose the appropriate degree of frequency. RFEs have the reproducibility "Always," since the feature is always missing, until the issue is resolved.
- Select Profile: In your personal preferences you can create user profiles for your reports. This is especially useful if you use more than one operating system or Distribution. You create a profile for each operating system, and if you file a report on an issue that occured on a particular system, you can simply choose the profile instead of inserting the data (Platform, OS, OS Version) by hand all the time.
- Platform: Insert your CPU platform (e. g. x86, x86-64, PPC, SPARC)
- OS: Your operating system (e.g. Linux, Windows, OS X)
- OS Version: e. g. Debian 3.1, SuSE 10.1, Win2000, OS X 10.3
- Product Version: Scribus has many incarnations: the stable branch, the developer branch with some more or less stable versions (1.3.xSVN, 1.5SVN etc.). Make sure you choose the right one from the drop down menu.
- Product Build: This is especially important if you are using SVN versions of Scribus. You find the relevant date in Scribus under Help > About Scribus. The date is very important, because the source code changes almost daily. An issue you report with an older version may very well already be resolved, in which case you will receive the recommendation to try the latest SVN version. Please don't report issues for depracated versions of Scribus.

If you have finished the preparations, you can finally start writing:

- Summary: A short description of your report. This will become the "headline" in the bug tracker.
- Description: Describe your issue as precisely as possible, but keep it concise. No Novels here! It may also be helpful to upload some screenshots (see below). If you file a feature request, please add a real world scenario. The team needs examples to understand what the idea is and how this new feature would help people to work better and more efficiently. In other words, try to describe not only what and how, but also why.
- Steps to reproduce: If you are able to reproduce a bug, please write down the steps necessary for reproduction on other machines.
- Additional information: If you think other information, e.g. postings from the mailing list or messages from a debugger, are useful in this context, you can add them here.

You're almost done now, but you may want to upload a file, a screenshot for instance, or a Scribus sample file. Click Searchor enter the path to the file on your hard drive or a URL.

If you don't want a report to be seen by other reporters, but only the team, you can switch the status to "Private." This may be the case if you discover issues with a file that is protected by copyrights. Check "Private," and only a handful of people will see the file.

Once everything is to your satisfaction, click Submit Report, and you're done.

# Personalised View

Provided you are logged in, you can choose a more clearly laid out view of the bugtracker. Click on the link My view, and Mantis will present a structured view of recently changed issues:

- Left column: Unassigned reports, resolved reports, and reports monitored by you.
- Right column: Your reports, all reports recently modified.