## Filing a Bug report

Successful software development is almost hopeless 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. Sometimes the fix may simply be a documentation update. 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 let the Scribus Team know about it.

In all cases, the procedure is the same. There exists a software category called bug tracking systems, which allows developers to keep track of, discuss and review bug reports and RFEs (requests for enhancement). The Scribus Team has decided to use the Mantis bug tracking system. If you want to help with improving Scribus or absolutely need a feature, you are advised to learn how to use it.

## Creating an Account

While there is a sign-up page, account creation by anyone but administrators had to be disabled due to massive spam attacks. If you want to contribute by reporting bugs or requests for enhancements, you can either write an email to the developer mailing list or contact a member of the Scribus Team directly, who will then create an account for you.

Once your account has been confirmed and you received a password via e-mail, 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 Report

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 Online Documentation, rummage the Scribus Wiki, or even consider buying the Official Scribus Manual. There is a lot of information available in various languages, 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. The use of Scribus is not hard to learn, but it is still quite different from, say, a word processor.
3. Post your problem or your idea on one of the mailing lists. 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 can 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 language to English in the Preferences.

You will notice that Mantis uses different colors to indicate the status of the reports. The meaning of the different colors is:

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

- New: The bug/RFE has been 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 will be changed to “acknowledged.” This is mostly the case with RFEs.
- Confirmed: If a reported bug could be reproduced by others, the status will be changed to “confirmed.” This is what usually happens to bug reports.
- Assigned: A bug or RFE has been assigned to a developer for fixing it or adding a feature.
- Resolved: A bug or RFE has been 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.

## Filing 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 can create a profile for each operating system, and if you file a report on an issue that occurred on a particular system, you can simply choose the profile instead of inserting the data (Platform, OS, OS Version) repeatedly all the time.
- Platform: Insert your CPU platform (e.g. x86, x86-64, PPC, SPARC) here.
- OS: Your operating system (e.g. Linux, Windows, Mac OS X, OS/2, eCS).
- OS Version: e.g. Debian 3.1, OpenSUSE 11.2, Windows XP, OS X 10.5, eCS 1.2
- Product Version: Scribus exists in several incarnations, e.g. the stable branch or the developer branch with some more or less stable versions (1.4.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. Note that you won’t find the relevant date in Scribus under Help > About Scribus, as this string will be updated by the developers only occasionally. The date that matters is the one of your SVN checkout, because the source code changes almost daily. An issue you report with an older version may have already been resolved, in which case you will receive the recommendation to try the latest SVN version. Please don’t report issues for deprecated versions of Scribus.

Once you have finished the preparations, you can finally start writing your report:

- 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 – please don’t write any 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 computers.
- 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 “Search” or 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 developers, 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.

## Personalized 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.