TrackerItemsUeberarbeiten - Revision history

Sordon: /* Tracker Items Überarbeiten */

2006-01-25T19:24:30Z

Tracker Items Überarbeiten

← Older revision		Revision as of 19:24, 25 January 2006
Line 8:		Line 8:
	# Dokumentiere deine Lösung. Wenn du einen Fehler behebst und schließt, dann füge einen Kommentar hinzu, wie du es geschafft hast (besonders wichtig: Welche Dateien wurden verändert und wonach sollte in diesen Ausschau gehalten werden?).		# Dokumentiere deine Lösung. Wenn du einen Fehler behebst und schließt, dann füge einen Kommentar hinzu, wie du es geschafft hast (besonders wichtig: Welche Dateien wurden verändert und wonach sollte in diesen Ausschau gehalten werden?).
	# Priorisierung: Obwohl SF zehn Prioritätsstufen pro Fehler erlaubt, besteht doch kein Bedarf für mehr als vier: "high" (9), "med" (6), "low" (3) und "unprioritized" (5). Wir benutzen die Priorisierung mehr für die "Gefährlichkeit" als für die Implementierungsreihenfolge (die sowieso unvorhersagbar ist).		# Priorisierung: Obwohl SF zehn Prioritätsstufen pro Fehler erlaubt, besteht doch kein Bedarf für mehr als vier: "high" (9), "med" (6), "low" (3) und "unprioritized" (5). Wir benutzen die Priorisierung mehr für die "Gefährlichkeit" als für die Implementierungsreihenfolge (die sowieso unvorhersagbar ist).
			## "Crash"-Fehler sind generell und immer "high" (9), genau wie Fehler, die mit dem Öffnen und Speichern, Dateifehlern, Backupverlust oder anderen Datenverlust verursachenden Zuständen zu tun haben oder Benutzer daran hindern, die Applikation überhaupt zu verwenden.
	** "Crash"-Fehler sind generell und immer "high" (9), genau wie Fehler, die mit dem Öffnen und Speichern, Dateifehlern, Backupverlust oder anderen Datenverlust verursachenden Zuständen zu tun haben oder Benutzer daran hindern, die Applikation überhaupt zu verwenden.		## Fehler, welche die Benutzbarkeit, die Funktionalität und das Verhalten der Anwendung beeinflussen, sind generell "medium" (6). Wichtige Fehler können jedoch hoch- und unwichtige herabgestuft werden.
			## Spontane Fehler, wirkliche Merkwürdigkeiten und unwichtige Haarspaltereien sind als "low" (3) einzustufen.
	** Fehler, welche die Benutzbarkeit, die Funktionalität und das Verhalten der Anwendung beeinflussen, sind generell "medium" (6). Wichtige Fehler können jedoch hoch- und unwichtige herabgestuft werden.

	** Spontane Fehler, wirkliche Merkwürdigkeiten und unwichtige Haarspaltereien sind als "low" (3) einzustufen.

	:Die Priorität sagt nichts darüber aus, wann der Fehler behoben sein wird. Fehler werden dann behoben, wenn ihre Zeit gekommen ist. Trotzdem strengen wir uns extra an, alle kritischen Fehler vor einem Release zu bearbeiten.		:Die Priorität sagt nichts darüber aus, wann der Fehler behoben sein wird. Fehler werden dann behoben, wenn ihre Zeit gekommen ist. Trotzdem strengen wir uns extra an, alle kritischen Fehler vor einem Release zu bearbeiten.

Conversion script: link fix

2006-01-22T02:33:47Z

link fix

New page

=== Tracker Items Überarbeiten===

Hier ein paar generelle Regeln für den Umgang mit [[SourceForge]] (SF) Bug-, Feature- und Patch-Tracker-Einträgen:

# Sei höflich. Es kostet den Benutzer einiges an Arbeit, auf unsere Seite zu surfen, zur Fehlermeldung zu navigieren und schließlich einen Fehlerbericht zu schreiben. Wenn du dir darüber im Klaren bist, dass dein Beitrag ernsthaft und professionell bearbeitet wird, wirst du das System wertschätzen und gerne ein wenig mehr Zeit investieren, um uns bei der Lösung des Problems zu unterstützen.
# Schließe keinen nichtreproduzierbaren Fehler, solange die Anstrengungen zur Reproduktion nicht schon jedes vernünftige Maß überschritten haben. Stattdessen lass ihn noch eine Weile "schmoren", vielleicht kommt jemand über die Kommentare mit einer besseren Beschreibung herüber. In ein paar Fällen, in denen wir nicht in der Lage waren, den Fehler nachzustellen, kamen wir über die Mithilfe der Benutzer näher an die Problemursache heran und waren schließlich in der Lage, das Problem zu beheben.
# Erzeuge Klarheit und Verständlichkeit. Wenn es dich schon eine Weile gekostet hat, herauszufinden, worum es geht, dann nimm dir noch ein wenig mehr Zeit, um den Titel umzuschreiben oder einen Kommentar hinzuzufügen. Dadurch wird es für die Personen, die nach dir im Tracker lesen, umso klarer (besonders wenn das die Person ist, die den Fehler beheben kann).
# Dokumentiere deine Lösung. Wenn du einen Fehler behebst und schließt, dann füge einen Kommentar hinzu, wie du es geschafft hast (besonders wichtig: Welche Dateien wurden verändert und wonach sollte in diesen Ausschau gehalten werden?).
# Priorisierung: Obwohl SF zehn Prioritätsstufen pro Fehler erlaubt, besteht doch kein Bedarf für mehr als vier: "high" (9), "med" (6), "low" (3) und "unprioritized" (5). Wir benutzen die Priorisierung mehr für die "Gefährlichkeit" als für die Implementierungsreihenfolge (die sowieso unvorhersagbar ist).

** "Crash"-Fehler sind generell und immer "high" (9), genau wie Fehler, die mit dem Öffnen und Speichern, Dateifehlern, Backupverlust oder anderen Datenverlust verursachenden Zuständen zu tun haben oder Benutzer daran hindern, die Applikation überhaupt zu verwenden.

** Fehler, welche die Benutzbarkeit, die Funktionalität und das Verhalten der Anwendung beeinflussen, sind generell "medium" (6). Wichtige Fehler können jedoch hoch- und unwichtige herabgestuft werden.

** Spontane Fehler, wirkliche Merkwürdigkeiten und unwichtige Haarspaltereien sind als "low" (3) einzustufen.

:Die Priorität sagt nichts darüber aus, wann der Fehler behoben sein wird. Fehler werden dann behoben, wenn ihre Zeit gekommen ist. Trotzdem strengen wir uns extra an, alle kritischen Fehler vor einem Release zu bearbeiten.