Difference between revisions of "Moderating the bug tracker/de"

From Lazarus wiki
m (Festlegen des Ziels)
(Spelling, wording & translations)
 
Line 3: Line 3:
 
Dieses Dokument enthält einige Richtlinien für die Verwendung des Lazarus [http://www.freepascal.org/mantis/main_page.php bug tracker]. Es wurde geschrieben für zwei Gruppen:
 
Dieses Dokument enthält einige Richtlinien für die Verwendung des Lazarus [http://www.freepascal.org/mantis/main_page.php bug tracker]. Es wurde geschrieben für zwei Gruppen:
 
* Lazarus Entwickler, die versuchen werden die [[Glossary#Bug|Bugs]] zu berichtigen
 
* Lazarus Entwickler, die versuchen werden die [[Glossary#Bug|Bugs]] zu berichtigen
* Moderatoren, die die Bearbeitung eines issue unterstützen werden durch setzen von Prioritäten und Sicherstellung der Reproduzierbarkeit.
+
* Moderatoren, die die Bearbeitung eines Issue unterstützen, in dem sie Prioritäten setzen und die Reproduzierbarkeit sicher stellen.
 
Wir werden den Ausdruck '''Lazarus Team''' für beide Gruppen verwenden.
 
Wir werden den Ausdruck '''Lazarus Team''' für beide Gruppen verwenden.
  
== Lebenszyklus eines issue ==
+
== Lebenszyklus eines Issue ==
Ein issue kann den folgenden Status haben:
+
Ein Issue kann den folgenden Status haben:
* new: er wurde in den bug tracker eingegeben
+
* new: er wurde in den Bug Tracker eingegeben
* acknowledged: das Lazarus Team hat den issue gesehen und sein Ziel gesetzt
+
* acknowledged: das Lazarus Team hat den Issue gesehen und sein Ziel gesetzt
* assigned: der issue wurde einem der Lazarus Entwickler zugewiesen, der versuchen wird, ihn zu berichtigen
+
* assigned: der Issue wurde einem der Lazarus Entwickler zugewiesen, der versuchen wird, ihn zu berichtigen
* confirmed: ein Mitglied des Lazarus Teams hat den Bug dupliziert oder zugestimmt, daß das Feature implementiert werden sollte
+
* confirmed: ein Mitglied des Lazarus Teams hat den Bug dupliziert oder zugestimmt, dass das Feature implementiert werden sollte
* resolved: die Person, der der issue zugewiesen wurde, ist der Meinung, daß der issue geschlossen werden kann. Dann setzt sie auch die Auflösung, zum Beispiel '''fixed''' oder '''not an issue'''.
+
* resolved: die Person, der der Issue zugewiesen wurde, ist der Meinung, dass der Issue geschlossen werden kann. Dann setzt sie auch die Auflösung, zum Beispiel '''fixed''' oder '''not an issue'''.
  
 
== Wie können Moderatoren die Lazarus Entwickler unterstützen ==
 
== Wie können Moderatoren die Lazarus Entwickler unterstützen ==
  
=== Bestätigen von issues ===
+
=== Issue akzeptieren ===
==== Festlegen des Ziels ====
 
Der wichtigste Schritt wenn sie einen issue bestätigen ist, daß sie das Ziel Feld festlegen. Das Ziel Feld hilft den Lazarus Entwicklern, ihre  Bugbereinigungsanstrengungen zu priorisieren. Im Allgemeinen gibt es drei Optionen: '''next release''', '''1.0''' oder '''post 1.0'''. Für eine Erläuterung dieser Optionen siehe [[Road To 1.0#1.0 or after 1.0]].
 
  
* next release: Patches, Rückschritte (das heißt Dinge, die im aktuellen Release funktionieren, aber in der [[Glossary#SVN|SVN]] Version kaputtgegangen sind) und Abstürze, die einen Datenverlust verursachen können.
+
==== Ziel festlegen ====
 +
Der wichtigste Schritt wenn sie einen Issue bestätigen ist, dass sie das Ziel Feld festlegen. Das Ziel Feld hilft den Lazarus Entwicklern, ihre  Bugbereinigungsanstrengungen zu priorisieren. Im Allgemeinen gibt es drei Optionen: '''next release''', '''1.0''' oder '''post 1.0'''. Für eine Erläuterung dieser Optionen siehe [[Road To 1.0#1.0 or after 1.0]].
 +
 
 +
* next release: Patches, Rückschritte (das heißt Dinge, die im aktuellen Release funktionieren, aber in der [[Glossary#SVN|SVN]] Version kaputt gegangen sind) und Abstürze, die einen Datenverlust verursachen können.
 
* 1.0: Lazarus 1.0 wird stabile Unterstützung für die win32 und gtk2 Schnittstelle enthalten.
 
* 1.0: Lazarus 1.0 wird stabile Unterstützung für die win32 und gtk2 Schnittstelle enthalten.
* post 1.0: andere widget sets und neue Features.
+
* post 1.0: andere Widget-Sets und neue Features.
  
==== Entfernung doppelter Einträge ====
+
==== Doppelte Einträge entfernen ====
Wenn sie einen neuen issue anschauen, dann können sie auch Duplikate entfernen die entstanden, weil Leute den selben issue mehr als nur einmal eingereicht haben. Manchmal benötigt der bugtracker eine lange Zeit zur Verarbeitung des neuen Reports und der Reporter wird ungeduldig und klickt erneut auf submit. Solche issues können gelöscht werden.
+
Wenn sie einen neuen Issue anschauen, dann können sie auch Duplikate entfernen, die dadurch entstehen, dass Leute den selben Issue mehr als nur einmal einreichen. Manchmal benötigt der Bug-Tracker eine lange Zeit zur Verarbeitung des neuen Reports und der Reporter wird ungeduldig und klickt erneut auf submit. Solche Issue können gelöscht werden.
  
==== Fragen an die Mailing Liste und Foren verweisen ====
+
==== Fragen an die Mailing-Liste und Foren verweisen ====
Wenn ein issue keinen Bug beschreibt, es nur eine Frage ist oder der Reporter nicht weiß, wie ein bestimmtes Feature zu benutzen ist, können sie ihn an die Mailing Liste verweisen und/oder die Foren, um seine Frage zu stellen. Dann können sie den issue mit der Auflösung ''not an issue'' beschliessen. Wenn sie wollen können sie auch eine kurze Antwort auf die Frage geben, aber der bug tracker ist da, um Bugs und Feature Anforderungen einzugeben, nicht um Support zu bieten.
+
Wenn ein Issue keinen Bug beschreibt, es nur eine Frage ist oder der Reporter nicht weiß, wie ein bestimmtes Feature zu benutzen ist, können sie ihn an die Mailing-Liste verweisen und/oder die Foren, um seine Frage zu stellen. Dann können sie den Issue mit der Auflösung ''not an issue'' schliessen. Wenn sie wollen können sie auch eine kurze Antwort auf die Frage geben, aber der Bug-Tracker ist da, um Bug- und Feature-Anforderungen einzugeben, nicht um Support zu bieten.
  
==== Verbindungen zu anderen issues hinzufügen ====
+
==== Verbindungen zu anderen Issues hinzufügen ====
Der bug tracker unterstützt das Setzen von Verbindungen zwischen issues.  
+
Der Bug-Tracker unterstützt das Setzen von Verbindungen zwischen Issues.  
  
 
Die schwächste Verbindung ist '''Related'''. Dies ermöglicht einfach einen Link zwischen den issues. Das kann nützlich sein, wenn sie einen issue berichtigt haben, mag es die verbundenen issues ebenfalls berichtigen.
 
Die schwächste Verbindung ist '''Related'''. Dies ermöglicht einfach einen Link zwischen den issues. Das kann nützlich sein, wenn sie einen issue berichtigt haben, mag es die verbundenen issues ebenfalls berichtigen.
  
Wenn zwei Reports die selben issues beschreiben, dann können sie den neueren Report auf '''Duplicate of''' setzen. Der andere Report erhält einen Link zu diesem issue mit '''Has duplicate'''.
+
Wenn zwei Reports die selben Issue beschreiben, dann können sie den neueren Report auf '''Duplicate of''' setzen. Der andere Report erhält einen Link zu diesem Issue mit '''Has duplicate'''.
  
Sie können die '''Parent - Child''' Verbindung zwischen zwei issues benutzen um die Abhängigkeit zu beschreiben. Um den '''Parent''' issue zu berichtigen, muß zuerst der '''Child''' issue berichtigt werden. Manchmal ist es nützlich, einen (großen) issue zu ''klonen'' und Teile davon in einem separaten '''Child''' issue zu beschreiben.
+
Sie können die '''Parent - Child''' Verbindung zwischen zwei Issues benutzen um die Abhängigkeit zu beschreiben. Um den '''Parent'''-Issue zu berichtigen, muss zuerst der '''Child'''-Issue berichtigt werden. Manchmal ist es nützlich, einen (großen) Issue zu ''klonen'' und Teile davon in einem separaten '''Child'''-Issue zu beschreiben.
  
==== Verweisen an den FPC bug tracker ====
+
==== An den FPC Bug-Tracker verweisen ====
Wenn ein Bug nicht in der [[Glossary#IDE|IDE]] oder der [[Glossary#LCL|LCL]] ist, aber in der [[Glossary#RTL|RTL]], [[Glossary#FCL|FCL]] oder dem [[Glossary#Compiler|Compiler]], dann können sie den issue zum FPC Projekt im bug tracker verschieben.
+
Wenn ein Bug nicht in der [[Glossary#IDE|IDE]] oder der [[Glossary#LCL|LCL]] ist, aber in der [[Glossary#RTL|RTL]], [[Glossary#FCL|FCL]] oder dem [[Glossary#Compiler|Compiler]], dann können sie den Issue zum FPC Projekt im Bug-Tracker verschieben.
  
 
=== Issues bestätigen ===
 
=== Issues bestätigen ===
Meistens ist der erste Schritt beim Berichtigen eines issues die Erstellung eines Beispielprogramms, das den issue zeigt. Wie schwierig das ist hängt von dem Aufwand ab, den der Reporter betrieben hat, als er den Report eingereicht hat. Einige Menschen liefern Testprogramme zu ihrem Report (sehr schön), einige Menschen nur einen Codeschnippsel (besser als nichts) und einige Menschen überhaupt nichts. Nicht alle Reports haben angemessene Schritte zum nachvollziehen.
+
Meistens ist der erste Schritt beim Berichtigen eines Issue die Erstellung eines Beispielprogramms, das den Issue zeigt. Wie schwierig das ist, hängt von dem Aufwand ab, den der Reporter betrieben hat, als er den Report eingereicht hat. Einige liefern Testprogramme zu ihrem Report (sehr schön), einige nur einen Codeschnippsel (besser als nichts) und einige überhaupt nichts. Nicht alle Reports haben angemessene Schritte zum nachvollziehen.
  
Wenn es nicht klar ist im Report, können sie den Reporter bitten, die Schritte zum nachvollziehen dieses issues zu nennen und/oder ein Testprojekt zu liefern.
+
Wenn es nicht klar ist im Report, können sie den Reporter bitten, die Schritte zum nachvollziehen dieses Issue zu nennen und/oder ein Testprojekt zu liefern.
  
Wenn es ihnen gelingt, den issue zu reproduzieren, dann können sie den issue auf '''Confirmed''' setzen.
+
Wenn es ihnen gelingt, den Issue zu reproduzieren, dann können sie den Issue auf '''Confirmed''' setzen.
  
 
== Tags ==
 
== Tags ==
  
Bellow is a table with the tags utilized to mark groups of bug reports which aren't easely defined by the other options and their description.
+
Die folgende Tabelle enthält Tags, mit denen man Gruppen von Bug-Reports markiert, die nicht leicht durch andere Optionen und Beschreibungen definiert werden können.
  
 
{| BORDER="1" CELLSPACING="0"
 
{| BORDER="1" CELLSPACING="0"
Line 57: Line 58:
 
!COLSPAN="1" STYLE="background:#ffdead;"|'''Beschreibung'''
 
!COLSPAN="1" STYLE="background:#ffdead;"|'''Beschreibung'''
 
|----
 
|----
|gtk2||Repräsentiert alle gtk2 spezifischen Bugs und dient zur Nachverfolgung, was noch erledigt werden muß, bevor gtk2 zum Vorgabe-Widgetset unter Linux werden kann.
+
|gtk2||Repräsentiert alle gtk2 spezifischen Bugs und dient zur Nachverfolgung, was noch erledigt werden muss, bevor gtk2 zum Standard-Widgetset unter Linux werden kann.
 
|}
 
|}

Latest revision as of 23:31, 7 October 2010

Deutsch (de) English (en) français (fr) português (pt) русский (ru)

Dieses Dokument enthält einige Richtlinien für die Verwendung des Lazarus bug tracker. Es wurde geschrieben für zwei Gruppen:

  • Lazarus Entwickler, die versuchen werden die Bugs zu berichtigen
  • Moderatoren, die die Bearbeitung eines Issue unterstützen, in dem sie Prioritäten setzen und die Reproduzierbarkeit sicher stellen.

Wir werden den Ausdruck Lazarus Team für beide Gruppen verwenden.

Lebenszyklus eines Issue

Ein Issue kann den folgenden Status haben:

  • new: er wurde in den Bug Tracker eingegeben
  • acknowledged: das Lazarus Team hat den Issue gesehen und sein Ziel gesetzt
  • assigned: der Issue wurde einem der Lazarus Entwickler zugewiesen, der versuchen wird, ihn zu berichtigen
  • confirmed: ein Mitglied des Lazarus Teams hat den Bug dupliziert oder zugestimmt, dass das Feature implementiert werden sollte
  • resolved: die Person, der der Issue zugewiesen wurde, ist der Meinung, dass der Issue geschlossen werden kann. Dann setzt sie auch die Auflösung, zum Beispiel fixed oder not an issue.

Wie können Moderatoren die Lazarus Entwickler unterstützen

Issue akzeptieren

Ziel festlegen

Der wichtigste Schritt wenn sie einen Issue bestätigen ist, dass sie das Ziel Feld festlegen. Das Ziel Feld hilft den Lazarus Entwicklern, ihre Bugbereinigungsanstrengungen zu priorisieren. Im Allgemeinen gibt es drei Optionen: next release, 1.0 oder post 1.0. Für eine Erläuterung dieser Optionen siehe Road To 1.0#1.0 or after 1.0.

  • next release: Patches, Rückschritte (das heißt Dinge, die im aktuellen Release funktionieren, aber in der SVN Version kaputt gegangen sind) und Abstürze, die einen Datenverlust verursachen können.
  • 1.0: Lazarus 1.0 wird stabile Unterstützung für die win32 und gtk2 Schnittstelle enthalten.
  • post 1.0: andere Widget-Sets und neue Features.

Doppelte Einträge entfernen

Wenn sie einen neuen Issue anschauen, dann können sie auch Duplikate entfernen, die dadurch entstehen, dass Leute den selben Issue mehr als nur einmal einreichen. Manchmal benötigt der Bug-Tracker eine lange Zeit zur Verarbeitung des neuen Reports und der Reporter wird ungeduldig und klickt erneut auf submit. Solche Issue können gelöscht werden.

Fragen an die Mailing-Liste und Foren verweisen

Wenn ein Issue keinen Bug beschreibt, es nur eine Frage ist oder der Reporter nicht weiß, wie ein bestimmtes Feature zu benutzen ist, können sie ihn an die Mailing-Liste verweisen und/oder die Foren, um seine Frage zu stellen. Dann können sie den Issue mit der Auflösung not an issue schliessen. Wenn sie wollen können sie auch eine kurze Antwort auf die Frage geben, aber der Bug-Tracker ist da, um Bug- und Feature-Anforderungen einzugeben, nicht um Support zu bieten.

Verbindungen zu anderen Issues hinzufügen

Der Bug-Tracker unterstützt das Setzen von Verbindungen zwischen Issues.

Die schwächste Verbindung ist Related. Dies ermöglicht einfach einen Link zwischen den issues. Das kann nützlich sein, wenn sie einen issue berichtigt haben, mag es die verbundenen issues ebenfalls berichtigen.

Wenn zwei Reports die selben Issue beschreiben, dann können sie den neueren Report auf Duplicate of setzen. Der andere Report erhält einen Link zu diesem Issue mit Has duplicate.

Sie können die Parent - Child Verbindung zwischen zwei Issues benutzen um die Abhängigkeit zu beschreiben. Um den Parent-Issue zu berichtigen, muss zuerst der Child-Issue berichtigt werden. Manchmal ist es nützlich, einen (großen) Issue zu klonen und Teile davon in einem separaten Child-Issue zu beschreiben.

An den FPC Bug-Tracker verweisen

Wenn ein Bug nicht in der IDE oder der LCL ist, aber in der RTL, FCL oder dem Compiler, dann können sie den Issue zum FPC Projekt im Bug-Tracker verschieben.

Issues bestätigen

Meistens ist der erste Schritt beim Berichtigen eines Issue die Erstellung eines Beispielprogramms, das den Issue zeigt. Wie schwierig das ist, hängt von dem Aufwand ab, den der Reporter betrieben hat, als er den Report eingereicht hat. Einige liefern Testprogramme zu ihrem Report (sehr schön), einige nur einen Codeschnippsel (besser als nichts) und einige überhaupt nichts. Nicht alle Reports haben angemessene Schritte zum nachvollziehen.

Wenn es nicht klar ist im Report, können sie den Reporter bitten, die Schritte zum nachvollziehen dieses Issue zu nennen und/oder ein Testprojekt zu liefern.

Wenn es ihnen gelingt, den Issue zu reproduzieren, dann können sie den Issue auf Confirmed setzen.

Tags

Die folgende Tabelle enthält Tags, mit denen man Gruppen von Bug-Reports markiert, die nicht leicht durch andere Optionen und Beschreibungen definiert werden können.

Tag Beschreibung
gtk2 Repräsentiert alle gtk2 spezifischen Bugs und dient zur Nachverfolgung, was noch erledigt werden muss, bevor gtk2 zum Standard-Widgetset unter Linux werden kann.