LHA-Tickets
Über den Menüpunkt "Neues Ticket" kommst du, wie der Name vermuten lässt, zur Eingabemaske für neue Tickets. Im folgenden sollen die einzelnen Eingabefelder und die Optionen beschrieben werden. Solltest du bei einzelnen Feldern zweifeln, kannst du gerne die vorbelegten Standardwerte verwenden.
Kurzbeschreibung
Eine knappe Beschreibung, die das Problem oder den Vorgang zusammenfaßt.
Ersteller
Der Autor des Tickets wird durch das zwingend nötige Login vorbelegt.
Beschreibung
Der Hauptteil des Ticket. Eine gute Beschreibung sollte aussagefähig, genau und knapp sein. Bei der Eingabe kannst du auf die Wiki-Formatierung zurückgreifen. Auch Screenshots können verwendet werden. Mittels der Wiki-Formatierung [[Image(ticket:1:Bild.gif)]] kannst du die Anhänge auch direkt in den Text einbinden. Dabei ist 1 die jeweilige Ticketnummer. Details sind in Wiki-Formatierung#Images zu finden.
Typ
Die Art des Tickets.
- Fehler -- Das Ticket beschreibt einen Fehler
- Erweiterung -- Das Ticket beschreibt eine Erweiterung bzw. den Wunsch einer Erweiterung (Feature Request)
- Aufgabe -- Dieser Tickettyp wird üblicherweise eher von Entwicklern verwendet, um bestimmte Aufgaben zu speichern (ToDo-Liste)
- Sicherheit -- Mit diesem Tickettyp werden sicherheitsrelevante Fehler oder Erweiterungen gespeichert. Diese Tickets sind nicht öffentlich einsehbar.
Priorität
Die Wichtigkeit diese Vorgangs von niedrig bis dringend
Meilenstein
Die Liste der Versionen entsprechend dem Projektplan. In aller Regel sollte hier der Standardwert lha unplanned gesetzt bleiben.
Komponente
Der Teilbereich unserers Systems, den dieses Ticket betrifft. Bist du unsicher, so verwende bitte den Standardwert verschiedenes.
Version
Projektversion, auf die sich dieses Ticket bezieht. Dieses Feld wird normalerweise den Standardwert LHA Produktiv enthalten. Nur Betatester werden auch Fehler im Testsystem melden.
Schweregrad
Während die Priorität die zeitliche Dringlichkeit wiederspiegelt, beschreibt der Schweregrad die Auswirkungen des Tickets.
- belanglos -- Schönheitsfehler; z.B. ein Rechtschreibfehler
- geringfügig -- der Fehler schränkt den täglichen Betrieb nicht ein; z.B. der VATSIM-Status wird nicht angezeigt
- schwer -- der Fehler betrifft den täglichen Betrieb, kann aber umgangen werden (Workaround); z.B. im Linienbriefing fehlen die Wetterdaten
- kritisch -- der Fehler betrifft den täglichen Betrieb und kann nur mit hohem Aufwand umgangen werden; z.B. die Flugrückmeldung via XACARS funktioniert nicht. Manuelle Rückmeldung geht aber.
- blockierend -- der Fehler verhindert den täglichen Betrieb. Es gibt keinen Workaround; z.B. es können keine Flüge gebucht werden.
Stichworte
Stichworte, mit den dieses Ticket gekennzeichnet ist. Dies ist für das Suchen und die Berichteerstellung nützlich.
Kopie
Eine komma-getrennte Nutzerliste oder eMail-Adressen für Benachrichtigungen. Beachte bitte, dass dies keine Verantwortlichkeit oder irgend eine andere Festlegung beinhaltet. Das Feld entspricht einem CC-Feld bei eMails.
Verantwortlicher
Der Verantwortliche (Owner) für dieses Ticket. Dieses Feld wird automatisch basiered auf der ausgewählten Komponente belegt und kann beim erzeugen des Tickets leer bleiben.
Lösungen
Jedes Ticket durchläuft einen Lebenszyklus. Ist ein Ticket am Ende abgearbeitet so bekommt es den Status geschlossen (=closed) und eine Beschreibung, wie die Lösung für das Problem aussieht:
- fixed -- Das Problem wurde behoben
- invalid -- Das Ticket ist ungültig (nicht zu verwechseln mit das Problem ist ungültig)
- wontfix -- Das Problem wird nicht behoben bzw. der Entwicklungswunsch nicht umgesetzt (z.B. weil der Fehler in einem ohnehin veralteten Modul auftaucht)
- duplicate -- Das Problem wurde doppelt erfasst (z.B. weil 2 Benutzer parallel ein Problem berichten)
- worksforme -- Das Problem ist nicht reproduzierbar
- wiki -- Das Problem bzw. dessen Lösung ist im LeipzigAir Wiki erklärt
- forum -- Das Problem bzw. dessen Lösung ist im LeipzigAir Forum erklärt.
Zusätzlich kann durch den Entwickler noch das Feld Release Notes befüllt werden. Die Release Notes sind für die gesammelte Dokumentation von neuen Versionen hilfreich.
