## Fehlerberichte und Wünsche

Erfolgreiche Softare-Entwicklung ist ohne ausgiebiges Testen fast unmöglich, und für Scribus trifft dies selbstverständlich ebenso zu. Testen bedeutet, das Programm zu benutzen, insbesondere die Entwicklerversionen. Wenn Fehler entdeckt worden sind, müssen sie den Entwicklern mitgeteilt werden, damit diese wissen, daß etwas nicht funktioniert oder wenigstens zu funktionieren scheint, wie es soll, so daß der Fehler behoben werden kann. Manchmal kann die Fehlerbehebung schlicht in einer Aktualisierung der Dokumentation bestehen. Darüber hinaus müssen die Entwickler natürlich wissen, welche Funktionen Anwender benötigen, und wenn eine bestimmte Funktion fehlt oder wenn jemand eine großartige Idee hat, sollte er es dem Scribus-Team mitteilen.

Ob nun Fehlerbericht oder Wunsch, die Prozedur ist in allen Fällen dieselbe. Es gibt eine spezielle Softwaregattung namens »Bug Tracking System«, die es Entwicklern erlaubt, Fehlerberichte und sogenannte »RFEs« (requests for enhancement) zu verfolgen und zu diskutieren. Das Scribus-Team hat sich für das Mantis-System entschieden. Wenn Sie also helfen wollen, Scribus zu verbessern oder unbedingt eine Funktion benötigen, sollten Sie lernen, wie man das System benutzt.

### Ein Benutzerkonto erstellen

Besuchen Sie die Anmeldungsseite. Sie werden eine Seite sehen, die in etwa wie folgt aussieht:

Geben Sie einen Benutzernamen, Ihre E-Mail-Adresse und die eingeblendeten Ziffern ein. Dann klicken Sie auf »Signup« und warten Sie, bis Ihr Nutzerkonto bestätigt wurde und Sie ein Paßwort per E-Mail erhalten haben. Sie können Ihre persönlichen Einstellungen jederzeit unter »My account« ändern, wenn Sie eingeloggt sind. Am besten nehmen Sie sich ein bißchen Zeit, um sich mit den verschiedenen Optionen vertraut zu machen und zu entscheiden, ob Sie für Sie von Nutzen sind.

### Bevor Sie einen Fehlerbericht einsenden

Wenn etwas nicht funktioniert wie erwartet, oder falls Sie glauben, Sie hätten die Idee des Jahrhunderts, fangen Sie bitte nicht gleich an, neue Einträge zu machen, denn es ist nicht auszuschließen, daß jemand schon über dasselbe Problem gestolpert ist oder dieselbe Idee hatte. Wir empfehlen, folgende fünf Schritte zu beachten, um sicherzustellen, daß Ihr Eintrag nicht umgehend als »Duplicate« oder »No change required« geschlossen wird..

1. Lesen Sie diese Online-Hilfe, stöbern Sie im Scribus Wiki, oder kaufen Sie das offizielle Scribus-Handbuch. Es sind reichhaltige Informationen in verschiedenen Sprachen vorhanden, und vielleicht hat schon jemand seine Erfahrungen in einen Wiki-Artikel gegossen, oder das Scribus-Dokumentationsteam hat die Online-Hilfe schon entsprechend erweitert.
2. Versuchen Sie wirklich, Scribus und das zugrundeliegende Konzept DTP zu verstehen. Scribus ist nicht schwer zu benutzen, aber es unterscheidet sich gewaltig von einem Textverarbeitungsprogramm.
3. Melden Sie Ihr Problem versuchsweise erst einmal auf einer der Mailinglisten. Normalerweise werden Probleme dort schnell geklärt, denn sehr oft ist ein vermuteter Fehler nur der Mangel an Erfahrung.
4. Stellen Sie im IRC Fragen. Dieser eignet sich besonders für Unterstützung in »Echtzeit«.
5. Wenn Ihre Fragen dann immer noch nicht beantwortet sind, können Sie in der Datenbank des Bugtrackers mit Hilfe von Stichwörtern suchen. Wie Sie auf der Abbildung weiter unten sehen, können Sie ein Stichwort in das Feld »Search« eingeben. Klicken Sie anschließend »Apply«, und Mantis wird nach allen Einträgen mit diesem Stichwort suchen. Wenn Sie das korrekte englische Wort nicht kennen, mag es helfen, die Scribus-Benutzeroberfläche kurzfristig auf Englisch umzustellen. Sie können aber auch das mehrsprachige Glossar benutzen.

Sie werden bemerken, daß Mantis verschiedene Farben benutzt, um den Status eines Berichts anzuzeigen. Die Farben bedeuten im einzelnen:

Neu | Feedback | Akzeptiert | Bestätigt | Zugewiesen | Gelöst | Geschlossen

- New (Neu): Der Fehlerbericht/RFE wurde eingetragen, aber es ist noch keine Entscheidung über das weitere Vorgehen gefallen.
- Feedback: Es wird eine Rückmeldung entweder vom ursprünglichen Einträger oder vom Verfasser eines Kommentars erwartet. Dies kommt häufig vor, wenn sich ein Fehler nicht reproduzieren läßt oder der Fehlerbericht unverständlich ist.
- Acknowledged (Akzeptiert): Wenn das Team entschieden hat, daß ein Vorschlag es wert ist, zukünftig bei der Entwicklung berücksichtigt zu werden, erhält der Eintrag den Status »Acknowledged.« Dies betrifft überwiegend RFEs.
- Confirmed (Bestätigt): Wenn ein Fehlerbericht von anderen reproduziert werden kann und sich der Fehler beheben läßt (d.h. wenn es ein Problem von Scribus ist), wird der Status zu »Confirmed« geändert. Dies betrifft überwiegend Fehlermeldungen.
- Assigned (Zugewiesen): Der Fehlerbericht oder RFE wurde einem Entwickler zugewiesen, um den Fehler zu beheben oder die neue Funktion zu programmieren.
- Resolved (Gelöst): Der Fehler wurde behoben oder die neue Funktion hinzugefügt. Es kann aber auch sein, daß sich der Fehler nicht beheben läßt, etwa wenn das Problem in einer externen Bibliothek liegt. Auch in diesem Fall erhält der Eintrag den Status »Resolved«.
- Closed (Geschlossen): Das Ende der Lebensspanne eines Eintrages. Wenn alles geklappt hat, wird er geschlossen, und die furchterregende Zahl der Wünsche und Fehlerberichte ist ein wenig kleiner geworden.

## Einen Fehlerbericht einsenden

Um einen Eintrag zu tätigen, müssen Sie auf »Report Issue« in Ihrem Browser klicken. Ihnen wird jetzt eine große Zahl von Feldern für Einträge präsentiert:

- Categories: Wählen Sie eine Kategorie, von der Sie denken, daß ihr Eintrag dort am besten hineinpaßt. Sollten Sie keine finden, wählen Sie »General«.
- Reproducibility: Wenn Sie einen Fehler melden, können Sie ihn reproduzieren? Wie oft tritt er auf? Wählen Sie die passende Häufigkeit des Auftretens. RFEs haben immer den Wert »Always«, weil die Funktion fehlt, bis der Eintrag als gelöst gekennzeichnet ist.
- Select Profile: In Ihren persönlichen Einstellungen können Sie Benutzerprofile für Ihre Berichte anlegen. Dies erweist sich besonders dann als nützlich, wenn Sie mehrere Betriebssysteme verwenden. Sie können so ein Profil für jedes Betriebssystem erzeugen, und wenn Sie einen Fehlerbericht einsenden, der sich nur auf ein bestimmtes System bezieht, wählen Sie einfach das Profil, anstatt jedesmal alles per Hand einzugeben.
- Platform: Hier sollten Sie die Hardware-Plattform angeben (z.B. x86, x86-64, PPC, SPARC).
- OS: Ihr Betriebssystem (z.B. Linux, Windows, Mac OS X, OS/2, eCS).
- OS Version: Z.B. Debian 3.1, OpenSUSE 11.2, Windows XP, OS X 10.5, eCS 1.2
- Product Version: Es existieren mehrere Scribus-Versionen, z.Zt. der stabile (1.4.x) und der Entwicklerzeig (1.5). Geben Sie acht, daß Sie die richtige Version auswählen.
- Product Build: Dies ist besonders wichtig, wenn Sie Scribus aus den SVN-Quellen kompilieren of Scribus. Beachten Sie, daß Sie das entscheidende Datum nicht in Scribus unter Hilfe > Über Scribus finden werden, weil diese Datumsangabe nur unregelmäßig manuell aktualisiert wird. Das Datum, das zählt, ist das, an dem Sie die SVN-Quellen zum letztenmal aktualisert haben. Es könnte sein, daß der Fehler bereits behoben ist, wenn Sie ihn melden. In diesem Fall werden Sie die Empfehlung erhalten, SVN erneut zu aktualiseren und die Angelegenheit nochmals zu überprüfen. Bitte senden Sie keine Fehlerberichte für veraltete Versionen (d.h. Versionen vor 1.4.0) ein!

Wenn Sie mit den Formalitäten fertig sind, können Sie endlich anfangen, Ihren Bericht zu schreiben:

- Summary: Eine kurze Beschreibung des Inhalts. Dies wird die »Überschrift« des Berichts im Bugtracker sein, die andere zu sehen bekommen.
- Description: Beschreiben Sie hier das Problem so genau, aber auch so knapp wie möglich. Bitte schreiben Sie hier auf keinen Fall Romane! Es könnte auch hilfreich sein, Bildschirmschnapschüsse hochzuladen (s.u.). Wenn Sie einen RFE eintragen, ergänzen Sie Ihre Beschreibung mit einem realistischen Anwendungsfall. Das Team braucht manchmal Beispiele, um zu verstehen, was genau Ihre Idee ist und wie die neue Funktion Anwendern dabei helfen kann, effektiver zu arbeiten. In anderen Worten: Beschreiben Sie nicht nur das Was und das Wie, sondern auch das Warum.
- Steps to reproduce: Wenn Sie einen Fehler reproduzieren können, bitte schreiben Sie die Schritte auf, die zu dem Fehler führen, so daß andere versuchen können, den Fehler auf ihrem eigenen Rechner nachzuvollziehen.
- Additional information: Wenn Sie meinen, daß weitere Informationen, z.B. eine Diskussion auf einer Mailingliste, nützlich seien, können Sie diese hier angeben. Auch die Ausgabe eines Debuggers können Sie an diese Stelle kopieren.

Sie sind nun fast fertig, aber vielleicht möchten Sie noch eine Datei hochladen, zum Beispiel einen Bildschirmschnappschuß oder eine Scribus-Datei. Klicken Sie in diesem Fall auf »Search« oder geben Sie den Pfad zu der Datei oder eine URL ein.

Wenn Sie nicht möchten, daß außer den Entwicklern andere Ihren Bericht sehen, z.B. weil eine Beispieldatei vertrauliche Daten enthält, können Sie dem Bericht Status »Private«. In diesem Fall wird nur eine Handvoll Menschen, nämlich die Entwickler, die Daten zu Gesicht bekommen.

Sobald alles zu Ihrer Zufriedenheit eingetragen ist, klicken Sie »Submit Report«. Das war’s schon.

## Personalisierte Ansicht

Wenn Sie eingeloggt sind, können Sie sich eine übersichtlichere Ansicht des Bugtrackers anzeigen lassen. Klicken Sie dazu auf »My view«, und Mantis zeigt Ihnen eine besser strukturierte Übersicht der zuletzt geänderten Einträge:

- Linke Spalte: Nicht zugewiesene Einträge, gelöste Einträge und Einträge, die Sie beobachten.
- Rechte Spalte: Ihre eigenen Berichte, alle Berichte, die zuletzt geändert wurden.