Wenn Sie ein Problem mit Open Rails (ORTS) haben, egal um welches es sich handelt, ist das OR-Entwicklungsteam immer dankbar für Berichte über mögliche Fehler. Natürlich liegt es an den Entwicklern, zu entscheiden, ob es sich um einen echten Fehler handelt, aber in jedem Fall ist Ihre Meldung darüber ein wichtiger Schritt, um dem Entwicklungsteam bei der Verbesserung von Open Rails zu helfen.
Das Entwicklungsteam verwendet zwei Methoden, um Fehler im Auge zu behalten:
1. Sogenannte „evnetuelle Fehler“ werden in einem einfachen Forumsbeitrag gemeldet: Links siehe nächster Absatz. Dies geschieht, um Entwicklern die Möglichkeit zu geben, Probleme herauszufiltern, die durch Umstände verursacht werden, die das Entwicklungsteam nicht kontrollieren kann, wie beispielsweise beschädigte Inhalte.
2. Eindeutige Fehler sind Probleme, die ein Entwickler untersucht hat und die festgestellt haben, dass sie ein echtes Problem im Programmcode von Open Rails darstellen. Sie werden in unserem Bug Tracker unter https://bugs.Launchpad.net/or/ gemeldet (Registrierung ist erforderlich).
Wenn Sie ein Problem mit Open Rails feststellen, sollten Sie zunächst einen eventueller-Fehler-Bericht in einem der folgenden vom Open Rails-Entwicklungsteam überwachten Foren einreichen:
• Elvas Tower, Abschnitt „Vielleicht ist es ein Fehler“ im Open Rails-Unterforum. Dies ist das Forum, das vom OR-Entwicklungsteam am häufigsten überprüft wird.
• TrainSim.com, Abschnitt „Open Rails-Diskussion“ des Open Rails-Unterforums
• . . .Weitere Foren können in Zukunft hinzugefügt werden
Ein eventueller-Fehler-Bericht besteht aus einem einfachen Beitrag in einem neuen Thema im Forum. Der Titel des Themas sollte die Form „Open Rails V#### Bug: +++++“ haben, wobei #### die Versionsnummer der Open Rails-Version ist, mit der Sie Probleme haben, und ++ +++ ist eine kurze Beschreibung des Problems, das Sie haben. Dieses Format hilft den Entwicklern, sich schnell einen Überblick über das gemeldete Problem zu verschaffen.
Der erste Beitrag in diesem neu gestarteten Thema sollte weitere Informationen zu Ihrem Problem enthalten: Beginnen Sie mit der genauen Beschreibung des Problems, beschreiben Sie es in einer Erzählung und ergänzen Sie diese Beschreibung durch Screenshots, von Open Rails erstellte Fehlermeldungen usw.
Geben Sie als Nächstes klar an, welche Inhalte Sie verwendet haben (d. h. Strecke, Aufgabe, Pfad, Zugverband, Lokomotive und weiteres Rollmaterial; je nachdem, was zutrifft), ob es sich um Freeware oder Payware handelt, wie der genaue Name des heruntergeladenen Pakets lautete und wo es erhältlich ist. Natürlich ist es auch in Ordnung, einen Download-Link zu einer vertrauenswürdigen Website zu veröffentlichen oder Dateien direkt an den Beitrag anzuhängen.
Fahren Sie fort mit einer genauen Beschreibung dessen, was Sie getan haben, als das Problem auftrat (dies kann bereits im ersten Absatz enthalten sein, wenn das Problem mit dem Zugbetrieb zusammenhängt). Auch hier können Screenshots etc. hilfreich sein, um die Situation besser zu beschreiben.
Suchen Sie schließlich auf Ihrem Desktop nach einer Textdatei mit dem Titel „OpenRailsLog.txt“. Laden Sie diese Datei hoch und hängen Sie sie am Ende Ihres Beitrags an. Dies ist sehr wichtig, da die Protokolldatei alle relevanten Programmdaten enthält, die der Benutzer niemals sehen kann, und daher eine der wichtigsten Informationsquellen für den Entwickler ist, der versucht, Ihr Problem zu lösen.
Fügen Sie nach dem Absenden Ihres Beitrags weitere Informationen nur in zusätzlichen Beiträgen hinzu, um das Risiko zu vermeiden, dass andere Ihre Änderungen nicht bemerken. Bitte haben Sie außerdem etwas Geduld, wenn die Entwickler auf Ihren Bericht reagieren. Die meisten Foren werden nur einmal am Tag überprüft, daher kann es einige Zeit dauern, bis ein Entwickler Ihren Bericht sieht.
Wichtig: Je mehr Informationen ein Entwickler aus dem ersten Beitrag erhält, desto schneller kann er einen Fehler lokalisieren, identifizieren und schließlich beheben. Auf der anderen Seite gibt es Berichte der Form: „Ich habe ein Problem XYZ mit kürzlich installierten Open Rails.“ Kannst du mir helfen?" sind von geringem Nutzen, da zunächst alle benötigten Informationen abgefragt werden müssen.
Wichtig: Bitte melden Sie nicht überstürzt einen entschiedenen Fehler im Bug-Tracker, bevor ein Entwickler Ihr Problem als echten Fehler deklariert hat!
Die obige Beschreibung ist unten in komprimierter Form als „Prüfliste“ verfügbar.
Viele Fehlerberichte erreichen nicht einmal den Status eines entschiedenen Fehlers, da es sich um einen Inhalts- oder Benutzerfehler handelt. Einige eventueller Fehler werden jedoch irgendwann zu Decided Bugs erklärt. Solche gesicherten Fehler sollten Sie in unserem Bug-Tracker melden, wenn der Entwickler, der den Bericht entgegennimmt, Sie ebenfalls darum bittet.
Den Open Rails Bug Tracker finden Sie unter https://bugs.Launchpad.net/or/, indem Sie auf den Link „Fehler melden“ in der oberen Hälfte rechts auf dem Bildschirm klicken. Sie müssen sich bei Launchpad registrieren, um einen Fehler melden zu können.
Sobald dies erledigt ist, folgen Sie den Schritten, durch die die Software Sie führt: Kopieren Sie unter „Zusammenfassung“ die Kurzbeschreibung des Fehlers, den Sie auch als Forenthread-Namen für den Maybe-Bug-Bericht eingegeben haben, und fügen Sie ihn ein.
Sehen Sie sich als Nächstes die Liste der Themen an, mit denen Launchpad glaubt, dass Ihr Fehler damit zusammenhängt – vielleicht wurde Ihr Problem bereits gemeldet?
Wenn Sie mit keinem der vorgeschlagenen Fehler etwas anfangen können, klicken Sie auf die Schaltfläche „Nein, ich benötige einen neuen Fehlerbericht“ und fahren Sie fort.
Geben Sie im Feld „Weitere Informationen“ die gleichen Informationen ein, die Sie auch im Maybe-Bug-Bericht angegeben haben (Kopieren und Einfügen). Möglicherweise müssen Screenshots als Anhänge hinzugefügt werden und Sie müssen außerdem die Datei OpenRailsLog.txt erneut hochladen. Vergessen Sie nicht, alle Informationen, die Sie in zusätzlichen Beiträgen zum ursprünglichen Maybe-Bug-Bericht hinzugefügt haben, anzugeben und unten im Feld „Weitere Informationen“ einen Link zu letzterem hinzuzufügen.
Sobald Ihr Fehler gemeldet wurde, fügen Sie weitere Informationen nur in zusätzlichen Beiträgen hinzu, um das Risiko zu vermeiden, dass Entwickler die zusätzlichen Informationen verpassen.
Die obige Beschreibung ist unten in komprimierter Form als „Checkliste“ verfügbar.
Wichtig: Sagen Sie nicht „Alle Informationen sind im verlinkten Thread enthalten“, da das Durchsuchen eines Threads nach den entscheidenden Informationen eine wirklich lästige Aufgabe ist. Geben Sie stattdessen bitte im Feld „Weitere Informationen“ eine prägnante, aber vollständige Zusammenfassung des Maybe-Bug-Threads an.
Wichtig: Bitte beeilen Sie sich nicht, einen entschiedenen Fehler auf unserem Bug-Tracker zu melden, bevor ein Entwickler Ihren Maybe-Bug als echten Fehler deklariert hat!
Bitte posten Sie keine Feature-Anfragen als eventueller Fehler im Bug Tracker auf Launchpad!
Bitte melden Sie denselben Fehler nicht mehrmals, nur weil die erste Meldung nicht innerhalb kurzer Zeit Aufmerksamkeit erregt hat. Das Aufräumen der daraus resultierenden Verwirrung kann die Dinge noch weiter verlangsamen.
Bitte melden Sie Fehler nicht direkt an den Bug Tracker, wenn Sie nicht 100 % sicher sind, dass es sich um einen echten, schwerwiegenden Fehler handelt, oder wenn Sie nicht dazu aufgefordert wurden.
Lassen Sie sich von Fehlerstatus nicht beleidigen – sie klingen oft härter, als sie wirklich bedeuten, wie zum Beispiel „Ungültig“.
Erwarten Sie im Allgemeinen keine schnelle Reaktion – Probleme werden dann behandelt, wenn die Leute Zeit haben.
Bereiten Sie sich darauf vor, den ursprünglichen Bericht näher zu erläutern – es kann erstaunlich leicht passieren, dass wichtige Details vergessen werden, die andere benötigen, um Ihren Fehler zu finden und zu beheben. Stellen Sie sich also darauf ein, dass Ihnen weitere Fragen gestellt werden, bevor mit der Arbeit begonnen werden kann.
Vermeiden Sie Kommentare, die keine technischen oder relevanten Details enthalten. Wenn Sie aufzeichnen möchten, dass der Fehler Sie betrifft, verfügt Launchpad oben über eine spezielle Schaltfläche: „Betrifft Sie dieser Fehler?“.
Wenn Sie den Fortschritt des Fehlerberichts einer anderen Person verfolgen und E-Mail-Benachrichtigungen erhalten möchten, können Sie dies tun
Abonnieren Sie Bug-Mails über die Seitenleiste.
„Vielleicht-Fehler“
• Neues Thema im entsprechenden Unterforum
• Thementitel: „Open Rails V<version> Bug: <description>“
• Problembeschreibung, ergänzt durch Screenshots etc.
• Verwendete Inhalte (Route, Aktivität, Pfad, Zugverband, Lokomotive und Rollmaterial; zutreffendes auswählen); Freeware / Payware?; Paketname und Download-Speicherort/Download-Link
• Schilderung der Aktionen kurz vor und zum Zeitpunkt des Problems, ergänzt durch Screenshots etc.
• Protokolldatei anhängen (Desktop: OpenRailsLog.txt)
• Fügen Sie weitere Informationen nur in zusätzlichen Beiträgen hinzu
• Sei geduldig
Eindeutiger Fehler
• Melden Sie sich nur dann bei Bug Tracker, wenn Sie dazu aufgefordert werden
• https://bugs.Launchpad.net/or/ (Registrierung erforderlich) -> „Fehler melden“
• „Zusammenfassung“: Beschreibung aus dem Thementitel des Maybe-Bug-Berichts
• Suchen Sie nach ähnlichen, bereits gemeldeten Fehlern
• Komprimieren Sie den gesamten Maybe-Bug-Thread im Feld „Weitere Informationen“.
• Link zum ursprünglichen Maybe-Bug-Bericht hinzufügen
• Laden Sie OpenRailsLog.txt und erläuternde Screenshots usw. erneut hoch und hängen Sie sie an.
• Fügen Sie weitere Informationen nur in zusätzlichen Beiträgen hinzu
• Sei geduldig
• Neu – hier beginnen alle Fehler. Zu diesem Zeitpunkt wurde der Fehler noch nicht von den richtigen Personen untersucht, um zu prüfen, ob er vollständig ist oder ob weitere Details erforderlich sind.
• Unvollständig – ein Mitglied des Open Rails-Teams hat entschieden, dass der Fehler weitere Informationen benötigt, bevor er behoben werden kann. Die Person, die den Fehlerbericht erstellt hat, muss nicht diejenige sein, die die zusätzlichen Details bereitstellt. Ein Fehler, der 60 aufeinanderfolgende Tage lang unvollständig bleibt, wird automatisch entfernt.
• Meinung – Der Fehler wurde als Meinung identifiziert, was bedeutet, dass nicht klar ist, ob tatsächlich ein Fehler vorliegt oder wie sich die Dinge verhalten sollten.
• Ungültig – ein Mitglied des Teams glaubt, dass es sich bei dem Bericht eigentlich nicht um einen Fehlerbericht handelt. Dies kann daran liegen, dass Open Rails wie geplant und erwartet funktioniert, oder dass es sich einfach nur um Spam handelt. Der Fehler kann in den neuen Zustand zurückversetzt werden, wenn in den Kommentaren weitere Informationen oder Klarheit bereitgestellt werden.
• Kann nicht behoben werden – ein Mitglied des Teams hat entschieden, dass dieser Fehler derzeit nicht behoben wird. Wenn es sich bei dem Fehlerbericht um eine „Funktionsanfrage“ handelt, haben sie entschieden, dass die Funktion derzeit nicht gewünscht ist. Dieser Status bedeutet nicht, dass nie etwas passieren wird, aber normalerweise wird zunächst ein besserer Grund für die Behebung des Fehlers oder das Hinzufügen der Funktion benötigt.
• Bestätigt – ein Mitglied des Teams konnte den Fehler ebenfalls feststellen, indem es den Anweisungen im Fehlerbericht folgte.
• Triagiert – ein Mitglied des Teams hat dem Fehler die Wichtigkeitsstufe zugewiesen oder ihn einem bestimmten Meilenstein zugeordnet. Fehler müssen im Allgemeinen diesen Zustand erreichen, bevor die Entwickler sie im Detail betrachten möchten.
• In Bearbeitung – ein oder mehrere Mitglieder des Teams planen oder arbeiten gerade daran. Sie werden anhand des Beauftragtenfelds identifiziert.
• Fix Committed – Der Fix für den Fehlerbericht oder die Funktionsanforderung wurde abgeschlossen und in das Versionsverwaltungssystem Subversion eingecheckt. Dort erscheint der Fix normalerweise in der nächsten experimentellen Version.
• Fix veröffentlicht – Der Code mit der Fehlerbehebung wurde in einer offiziellen Version veröffentlicht.
Durch die Veröffentlichung eines Fehlerberichts in einem Forum oder im Launchpad entsteht für das OR-Entwicklungsteam keinerlei Verpflichtung, Haftung oder Verpflichtung, den Fehler zu untersuchen und zu beheben. Das OR-Entwicklungsteam entscheidet völlig freiwillig und autonom, ob es den Fehler untersucht und behebt.