Prozessverwaltung

Zuerst zwei Hinweise:
		 	
{| border="0" cellspacing="0" cellpadding="0" width="100%"	
{| style="width="30%"; font-size:95%; text-align:left; padding:-2px; background:none" cellpadding="0" cellspacing="0"	Beiträge	Beiträge
		 	
{| border="0" cellspacing="0" cellpadding="0" width="100%"	
{| style="width="30%"; font-size:95%; text-align:left; padding:-2px; background:none" cellpadding="0" cellspacing="0"	Keine individuelle Unterstützung	Keine individuelle Unterstützung
Die Allgemeine Prozessverwaltung befindet sich unter http://jira.secondlife.com. Es ist eine durchsuchbare Datenbank, die genutzt wird, um Prozesse und Vorgänge (z.B. Fehler oder Anfragen zur Änderung von Funktionen) zu gliedern und zu organisieren, die von der Second Life-Gemeinschaft eingereicht wurden. Sie können dort mithelfen, Informationen über Vorfälle zu liefern, die Sie bei der Benutzung der Open Source- oder Standardversion von Second Life herausgefunden haben. Die Informationen auf dieser Seite werden Ihnen helfen, sich mit dieser Einrichtung vertraut zu machen.
Um genau zu sein, ist JIRA ein prozessverwaltendes Projekt-Management Werkzeug, das von Atlassian geschaffen wurde. Es wird hauptsächlich von der Second Life Open Source Gemeinschaft genutzt und wird auch als "Allgemeines JIRA", "PJIRA" oder einfach "JIRA" bezeichnet, je nach Zusammenhang.
== Wie funktioniert's ==
Es gibt zwei Hauptarten von Vorgängen: Fehlermeldungen und Anfragen nach neuen Funktionen.
* Eine Fehlermeldung setzt sich zusammen aus einer Beschreibung des Problems UND einer Anleitung diesen Fehler zu reproduzieren.
* Eine Anfrage nach neuen Funktionen besteht aus ebenfalls einer Beschreibung und einer Skizze, wie die gewünschte Option funktionieren soll.
# Beide Arten von Vorgängen erhalten dann die Aufmerksamkeit anderer Residenten, die dann eigene, bessere oder einfachere Beschreibungen und Wege der Reproduktion hinzufügen können.
# Bei besonders beliebten Vorgängen können sich die Stimmen anderer Residenten häufen.
# Programmierer der Open Source-Gemeinschaft können Fehlerkorrekturen, sogenannte "Patches", oder Änderungen des Quellcodes hinzufügen, die jeweils das Problem beheben.
# Die Stimmen Anderer, genauso wie Veranstaltungen, wie z.B. die bug triages (Fehler-Notfallmaßnahmen), helfen, diesen Fall zu beschleunigen.
# Die Vofälle, die von Linden Lab bestätigt wurden, werden in die Linden-interne Kopie des JIRA "importiert". Das heißt, der Fehler wird untersucht und bearbeitet.
Nachdem der Fall die Aufmerksamkeit von Linden Lab hat, kann man weiterhin den aktuellen Sachstand nachverfolgen:
* Wenn einmal die Veränderungen abgeschlossen sind und die Veröffentlichung bevorsteht, wird die Anzeige zu "Fix Pending" (Behebung bevorstehend) verändert.
* Wenn die Veränderung in einer neuen Second Life-Version verfügbar ist, wird es als "Fixed" (Behoben) angezeigt.
* Generell gilt : Nachdem der Fehler von Linden Labs Quality Assurance Team und unserer Gemeinschaft als behoben und erledigt bestätigt wurde, wird der Status von "Resolved" (Beigelegt) auf "Closed" (Geschlossen) gesetzt.
Zusätzlich zu "Fix Pending" und "Fixed" kann ein Vorgang beigelegt werden, wenn sich herausstellt, das er ein Duplikat eines bereits bestehenden Vorgangs ist,er nicht reproduzierbar ist, er falsch abgelegt wurde, gar kein Fehler ist, usw. .
== Eine Fehlermeldung/Funktionsanfrage erstellen ==
Wenn Sie sich hilflos fühlen und nicht wissen, wo Sie anfangen sollen, schauen Sie sich dieses 15minütige Video (auf Englisch) an:
:<videoflash>Jofq8ClPfNg</videoflash>
=== Richtlinien einer Fehlermeldung ===
* Bieten Sie immer, immer Einzelschritte an. (Nummerieren Sie sie!) Wir können einen Fehler NUR DANN untersuchen, wenn wir nachvollziehen können, wie er entsteht. Je einfacher wir den Fehler reproduzieren können, desto schneller kann er behoben werden.
** Anstatt zum Beispiel zu sagen : "Ich stürze ab, wenn ich Dinge hochlade", sollte die Aleitung zur Reproduktion in genauen Schritten dargelegt werden:
**: 1. Ich klickte auf Datei > Bild hochladen ($L10)...
**: 2. Ich wählte eine .TXT-Datei anstatt eines .JPG-Bildes
**: 3. Klickte dann auf den "Öffnen"-Knopf
**: 4. MEINE BEOBACHTUNG: Ich stürzte zurück auf den Hauptbildschirm. Ein Absturzfenster erscheint nicht
** Probieren Sie, ihre Zusammenfassung einem Freund/einer Freundin zu schicken, um zu sehen, ob sie es nachvollziehen können. Wenn ihr Freund/ihre Freundin ihren Schritten folgen können, besteht die Aussicht, das wir es auch können!
* Ziehen Sie in Betracht ein Bildschirmfoto, ein Video, ein Absturzprotokoll oder andere damit verbundene Dateien anzufügen (10MB-Limit pro Datei). In dem oben genannten Beispiel sollten Sie daran denken, die Datei anzuhängen, die sie ursprünglich hochladen wollten und die dann den Absturz verursachte.
* Versuchen Sie nicht mehr als einen Fall pro Meldung zu schildern. Jeder einzelne Fehler braucht seine EIGENE Meldung um rückverfolgbar zu sein.
* Durchsuchen Sie zuerst andere Fälle, um sicherzugehen, das ihres kein Duplikat ist.
* Unterlassen Sie die Erwähnung anderer Residentennamen oder weiterer personenbezogener Daten! Wenn der Fehler nur Sie oder sehr wenige betrifft, sollten Sie weitere Hilfe über unser Support Portal in Betracht ziehen.
=== Auf dem Laufenden bleiben ===
# Sie können das Veröffentlichungsprotokoll überprüfen, um auf dem aktuellen Stand der letzten Änderungen bei Second Life zu bleiben. Manchmal entdecken sie die Zusammenhänge um einen Fehler oder sie finden eine gewollte Veränderung. Zum Beispiel nicht in der Lage zu sein, sein Land für L$ 0,- zu veräußern ist ein technisches Merkmal, kein Fehler!
# Desgleichen sollten Sie sicherstellen, dass ihre Grafikkartentreiber auf dem aktuellen Stand sind. Hinweis für Fortgeschrittene: Die Omega Treiber sind vielgenutzte, verbesserte Versionen dieser Treiber.
=== Bestimmen, ob der Fall bereits eingereicht wurde ===
Bevor Sie einen weitverbreiteten Systemfehler melden, sollten Sie zuerst schauen, ob bereits irgendwelche Informationen dazu vorhanden sind, indem Sie das Support Portal durchsuchen und nach den neuesten Statusmeldungen auf der Statusberichtsseite schauen.
Die Vermeidung von Duplikaten ist äußerst wichtig. Das Aussortieren von Duplikaten vergeuded Zeit und Aufwand (sowohl für Linden Lab Mitarbeiter als auch für helfende Residenten) und es läßt Fehlermeldungen und Funktionsanfragen vernachlässigter erscheinen als sie eigentlich sind. Es ist deutlich effizienter, die Anstrengungen auf dasselbe Problem in derselben Meldung zu konzentrieren, insbesondere da hochaktive Fälle eine höhere Dringlichkeit erhalten.
Nach dem Einloggen sehen Sie die Instrumententafel. Von hier aus haben Sie Zugriff auf einige Filter, die ihnen Zugang zu den aktuellsten Informationen bei den eingereichten Vorfällen geben.. Sie können zum Beispiel auf einen Filter klicken, der ihnen alle ungelösten Fälle innerhalb eines Projekts anzeigt und dann von da aus eine Textsuche starten (indem Sie den Filter verändern). Natürlich können Sie auch einfach eine neue Suche über den Quick Search: -Kasten starten. Welchen Weg Sie auch immer wählen, die beste Vorgehensweise ist es, vorher nach dem Fall zu suchen, den Sie melden möchten, bevor sie ihn tatsächlich einreichen!
::Wenn Sie herausfinden, das ihr Fall bereits eingereicht wurde, können Sie immer noch eine Menge tun, um zu helfen:
::* Hinterlassen Sie einen Kommentar mit Zusatzinformationen oder weiteren Details
::* Wenn es sich um einen Fehler handelt, zeigen Sie unter Umständen einen weiteren Weg auf, um diesen zu reproduzieren
::* Stimmen Sie für den Fall, um auszudrücken, das es ihnen wichtig ist.
::Je mehr gute und GENAUE Informationen es dort über einen Fall gibt, desto größer ist die Chance einer schnellen Lösung.
=== Wie man einen Fehler meldet ===
Um eine neue Fehlermeldung zu erstellen, verfahren Sie wie folgt:
# Klicken Sie auf den "Create New Issue"-Link im blauen Navigationsbalken an der Oberseite des Bildschirms. (Wenn sie den Link nicht sehen, stellen Sie sich , dass sie im JIRA eingeloggt sind.)
# Auf der ersten Seite:
#* Wählen Sie das Project (Projekt), das am ehesten dem Fehler entspricht, den Sie melden möchten - Lesen Sie dazu auch Projekte und Komponenten.
#* Wählen Sie "Bug" (Fehler) als ihren Issue type (Art des Falles).
#* Klicken sie auf "Next" (Weiter).
# Auf der zweiten Seite:
## Geben sie dem Fall einen prägnanten aber informativen summary (Titel)
## Wählen Sie die priority (Priorität, Dringlichkeit) des Fehlers. Ein "Showstopper" z.B. läßt das ganze Programm nutzlos werden. Ein "small" bug (Kleiner Fehler) aber, kann bloß Kosmetik sein. Klicken sie auf das Hilfe-Symbol neben dem Drop-down-Menu für weitere Details.
## Wählen sie die components (Komponente), die den Spielraum des Fehlers weiter eingrenzt. Sie können mehrere Komponenten wählen, wenn Sie die Strg-Taste gedrückt halten.
## Wählen Sie die betroffene Version aus (versions). Wählen Sie nur die Versionen aus, wo sie den entsprechenden Fehler auch selber bemerkt haben und nur dann eine "First Look" version aussuchen, wenn dieser Fehler ausschließlich bei einer solchen auftritt.
## Beschreiben Sie die Computerumgebung (environment) in welcher das Problem auftrat. Wenn Ihnen z.B. aufgefallen ist, das der Fehler nur in einer bestimmten Hardware- oder Softwarekonfiguration auftritt.
##* Die beste Methode an die Informationen zu gelangen, ist sie aus Second Life selbst zu kopieren. (Hilfe > Über Second Life...) Einige Sachverhalte könnten wichtig sein (Windows od. Mac od. Linuxrechner oder um welche Grafikkarte es sich handelt oder welches Headset benutzt wurde, wenn sich um Sprachfunktionalität handelt). Wenn die Konfiguration keine Rolle spielt, können Sie diesen Bereich auch leer lassen.
##* Zum Beispiel "Tritt nur bei Mac OS X 10.4.1 auf" oder "Nur bei einer NVIDIA GeForce Go 7800 Grafikarte bemerkt", etc.
## Geben Sie eine detailierte Beschreibung (description) des Falles und stellen Sie sicher, das er folgendes enthält:
##* Ablaufschritte (1,2,3...) um den Fehler verlässlich zu reproduzieren -- Was den Fehler erscheinen ließ. Wenn Sie die Einzelschritte nich eindeutig bestimmen können, beschreiben Sie was ihrer Meinung nach zu dem Fehler zu führen scheint. Versuchen Sie es so einfach wie möglich, aber immer noch genau genug, um den Fehler reproduzieren zu können. Einfachere Reproduktionen machen es leichter, den Grund des Fehler einzugrenzen.
##* BEOBACHTETE Ergebnisse (Was passiert, wenn der Fehler auftritt)
##* ERWARTETE Ergebnisse (Welches Verhalten hätten Sie stattdessen erwartet)
##* Erinnerung: Seien Sie so genau wie möglich ohne persönliche Informationen mit einzubeziehen!
## Wenn Sie ein Bildschirmfoto oder Video des Fehlers haben, können Sie das unter attachment anhängen. Bedenken Sie das 10MB Größenlimit pro Datei. Sie können weitere Dateien später noch hinzufügen. (Sehen sie unter Debug Help für weitere Wege, um nach Zusatzinformationen zu suchen.)
## Wenn Sie ein Programmierer sind und einen Patch für den Quellcode anfügen, geben Sie die source version an, für die der Patch gedacht ist und aktivieren Sie das patch attached Kästchen.
# Schliesslich klicken Sie auf "Create" ,um den neuen Fall zu erstellen.
=== Wie man eine neue Funktion einreicht/anfragt ===
Dieser Prozess ist ähnlich dem einer Fehlermeldung,mit den folgenden Unterschieden:
* Wählen Sie "New Feature" anstatt "Bug" als ihren Issue type.
* Anstatt einer Reproduktionsbeschreibung erklären Sie deutlich die gewünschte Implementation und Funktionalität, die Sie gerne hätten. Stellen Sie vorher fest, ob es das nicht schon gibt — Lesen Sie unseren Blog um zu sehen, was wir als nächstes vorhaben.
=== Wie man einen Sicherheitsvorfall meldet! ===
* Bitte melden Sie sicherheitsrelevante Fälle und Exploits direkt an unser Sicherheitsteam. ("Exploits" sind Fehler, die genutzt werden könnten, um sich einen Vorteil zu verschaffen, unerlaubten Zugriff auf Skripte zu erhalten, jedwedes nicht-autorisiertes manipulieren an Objekten, die man nicht selber erstellt hat (sogenannte 'Berechtigunsfehler') und weitere Fehler, die möglicherweise das Grid oder die Privatsphäre anderer kompromittieren könnten.)
* Für schnellstmögliche Ergebnisse mailen Sie bitte ihren Sicherheitsbericht an security@lindenlab.com. Lesen Sie dazu auch alles über Sicherheitslücken.
== Bleiben Sie höflich ==
Hinweis: Die Second Life Gemeinschaftsnormen gelten in allen Bereichen von Second Life, einschließlich der Allgemeinen Second Life Prozessverwaltung. Jeder Resident, der diese Richtlinien misachtet, kann von der weiteren Nutzung der Prozessverwaltung ausgeschlossen werden.
Beispiele von Verhalten oder Handeln, das zur Entfernung aus der Prozessverwaltung führen kann:
* Die Benutzung der Prozessverwaltung, um ein Geschäft, Blog, Webseite oder sonstiges Anliegen zu bewerben sowie alles, was nicht unmittelbar mit dem vorliegenden Fall zu tun hat.
* Flaming - Der Akt der Meldungseinstellung mit dem Ziel bewußt Streit hervorzurufen oder eine Person bzw. Personen direkt anzugreifen, nennt man "Flaming" und ist nicht für die Prozessverwaltung geeignet. Bitte bleiben Sie bei den Fakten des vorliegenden Falles. Meldungen und Kommentare, die das misachten, werden gelöscht.
* Privatdiskussionen - Das Verbreiten von persönlichen Meinungen oder unpassendes Geschwätz. Die Prozessverwaltung ist zur Lösungsfindung von Fehlern und Problemen gedacht. Wir lieben produktive Rückmeldungen. Bitte bleiben Sie bei den technischen Details der vorliegenden Angelegenheit.
* Bearbeitungskriege - Wiederholtes verändern eines Beschlusses, einer Dringlichkeitsstufe oder Klassifizierung eines Falles innerhalb der Prozessverwaltung.
== Stimmen Sie ab ==
Für neue Fehlermeldungen und Funktionsanfragen können Sie abstimmen, wenn Sie wünschen das diese von Linden Lab behoben werden sollen und hier finden Sie alle Fälle, nach der Anzahl der Stimmen. JIRA gebraucht das Beliebtheitsstimmrecht, daher können Sie für so viele oder wenige Fälle stimmen, wie sie möchten, sie haben immer 1 Stimme pro Fall.
Die Stimmen werden gerne als Teil unseres Priorisierungsprozesses genutzt. Bedenken Sie jedoch, das seit wir auf Aspekte wie etwa Machbarkeit oder die benötigte Entwicklungszeit achten müssen, ein Fall mit sehr vielen Stimmen nicht notwendigerweise vor einem mit weniger Stimmen gelöst wird, außer er ist machbar.
== Überprüfen Sie den Fallstatus ==
Linden Lab wird zu jira.secondlife.com eingereichte Fälle regelmäßig überprüfen. Das Ingenieursteam benötigt eventuell weitere Zusatzinformationen vom Erstelle oder anderen Teilnehmern, prüfen Sie daher gelegentlich nach, ob ihr Fall Kommentare oder Fragen von Linden Lab erhalten hat.
Wenn ihr Fall intern gelöst wurde, wird er auch in der Prozessverwaltung aktualisiert (sogar bevor er bereit ist in einer neuen Version verschickt zu werden). Überprüfen Sie daher regelmäßig ihren Fall auf Veränderungen und Aktualisierungen.
== Status ihres Falles ==
=== Mögliche Zustände ===
Hier nun, wie Linden Lab die verschiedenen Lösungszustände nutzt:
; Open (Offen): Hier obliegt es dem Bevollmächtigten den Fall zu lösen. Der Bevollmächtigte (Assignee) kann den Fall lösen oder ihn an die meldende person zurückverweisen, wenn er den Fall als "Resolved" (Gelöst) markiert (siehe unten).
; In Progress (In Bearbeitung): So signalisiert ein Entwickler jedem, das er/sie an dem Fall arbeitet.
; Reopened (Wiedereröffnet): das Gleiche wie "Open". Obwohl es bereits geschlossen war, ist es nun als immer noch ein Problem gemeldet worden, das einer Wartung bedarf.
; Resolved (Beigelegt): Dies ist eine Zuweisung zurück an den Erstmelder des Falles. Er ist noch nicht geschlossen, sondern eher in einer Art Schwebezustand von dem jetzt die Entscheidung abhängt. Es liegt bei dem Erstmelder zu entscheiden, ob der Fall wieder eröffnet werden soll oder ob er geschlossen wird.
:; Fixed (Behoben): bedeutet, das der Fehler in einer neuen Ausgabe von Second Life behoben wurde.
:; Fix Pending (Schwebend): bedeutet, dass der Fehler in einer bald verfügbaren Version oder einem Patch behoben sein wird.
:; Won't Fix (Nicht behoben): bedeutet, das der bevollmächtigte nicht glaubt, das dieser Fehler jemals behoben werden sollte oder in absehbarer Zukunft behoben werden kann.
:; Duplicate (Duplikat): bedeutet, das es bereit einen Fall gibt, der genau diesen Fehler/ diese Idee beinhaltet.
:; Needs More Info (benötigt mehr Info): Diesem Fall fehlt es an ausreichender Information. Bitte fügen Sie diese Informationen hinzu oder der Fall KANN NICHT weiter bearbeitet werden.
:; Cannot Reproduce (Nicht reproduzierbar): das bedeutet, wenn man den angegebenen Schritten folgt, das Problem nicht auftritt. Vielleicht müssen weitere Einstellungen, Handlungen oder Faktoren gegeben sein, damit dieses Problem auftritt. Bitte geben Sie eine genauere Beschreibung wie das Problem zu reproduzieren ist. Fälle, die nicht reproduzierbar sind, werden irgendwann geschlossen.
:; Misfiled (Falsch abgelegt): Dieser Fall gehört nicht in die Prozessverwaltung.
; Closed (Geschlossen): Der endgültige Ruheplatz. Erledigt!
== Häufig gestellte Fragen ==
Unter Bug Tracker/FAQ erhalten Sie Antworten auf häufige Fragen!
== Suchen ==
Um mehr Hilfe dazu zu bekommen, schauen Sie sich die Bug Tracker/Searching-Seite an!
== Wie kann ich Linden Lab helfen, Fehler zu verwalten? ==
Gut, das Sie fragen! 
=== Duplikate markieren ===
Wenn Sie einen neueren Fall bemerken, der ein Duplikat eines bereits bestehenden Falles ist, setzen sie diesen neuen Fall auf "Resolved" bzw. "Duplicate". Aber wenn Sie das tun, dann wählen Sie bitte außerdem "Link" und sagen dann "Dieser Fall ist ein Duplikat" und geben Sie die Hauptfehlernummer ein. So kann jeder nachvollziehen welche Fehler Duplikate von anderen sind und welche Fehler mehr als andere gemeldet werden. Das stellt sicher, das Fehler die öfter als andere gemeldet werden, größtmögliche Aufmerksamkeit erhalten und es ermöglicht, das die Duplikate von einer zentralen Stelle nachgeprüft werden können, um sicherzustellen, das es sich wirklich um Duplikate handelt.
=== Lösen von Hilfsanfragen ===
Diese überläßt man am besten den technisch versierten Benutzern, die den Unterschied zwischen einer Hilfsanfrage und einem Fehler ausmachen können -- es ist nicht immer einfach,das herauszufinden. Sie sollten am ehesten eine Meldung als "Resolved" markieren, wenn sie eine Hilfsanfrage zu sein scheint. Mit der Markierung als "Resolved" schiebt es die Verantwortung zurück an den Erstmelder, mehr Informationen zu liefern warum es sich hierbei tatsächlich um einen reproduzierbaren Fehler handeln soll.
=== Lösen von nicht reproduzierbaren Fehlern ===
Wenn man sich exakt an die Beschreibung der Fehlermeldung hält, in der identischen Computerumgebung und dennoch tauch dieser Fehler nicht auf, sollte man ihn auf "Resolved" setzen. Vorsicht : Wenn es sich um Grafikfehler handelt und Sie nicht die identische Grafikkarte haben, können sie das nicht bestimmen. Noch einmal : Das überläßt man am besten den technisch versierten Benutzern.
=== Fehler reproduzieren ===
Das ist extrem wichtig! Wenn sie eine Schritt-für-Schrittliste zur Reproduktion des Fehlers aus einer Fehlermeldung erstellen können, hilft das Linden Lab sich auf einwandfrei lösbare Fehler zu konzentrieren. Solange ein Fehler nicht reproduziert wurde, ist es unmöglich zu wissen, ob er gelöst wurde oder nicht. Halten sie sich an das, was der Melder sagt und schreiben sie eine solche Schritt-für-Schrittliste der Dinge, die Sie gemacht haben, damit es zum Auftreten des Fehlers kam. Fügen Sie ihre Ergebnisse dem entsprechenden Prozess hinzu und sagen Sie in den Kommentaren, dass Sie den Fehler erfolgreich reproduzieren konnten. Fehler mit einer stabilen Reproduktion bekommen höhere Dringlichkeitsstufen im Entwicklungsablauf und helfen dem Bug Triage Team effizienter zu arbeiten.
== Verwandte Themen ==
Möchten Sie mehr über die Prozessverwaltung lernen?
* Bug Tracker Forum Transcript - Infos von Rob and Aric Linden warum es die Prozessverwaltung gibt. Werfen Sie einen Blick "hinter die Kulissen" und erhalten sie weitere Antworten auf ihre Fragen.
* JIRA Benutzerhandbuch von Atlassian, Macher des JIRA
Category: Bug Tracker