[WIP] Bugtracker Eintrag im Wiki

  • Hallo JustChunkies,


    kurze Vorschlag zu einem Wiki-Eintrag für den Bugtracker meinerseits
    [hr][/hr]
    Titel: Bugtracker
    Synonyme: ???
    Kurzfassung:
    Über den Bugtracker wird die Entwicklung von JustChunks dokumentiert. Fehler werden dort gemeldet und auch Vorschläge für neue Funktionen können dort eingebracht werden. Der gesamte Prozess ist hierbei transparent gestaltet.
    Beschreibung:
    1. Übersicht
    Der Bugtracker ist ein Webinterface, erreichbar unter https://justchunks.net/bugtracker/. Strukturiert ist er nach logischen Kategorien die wiederum die einzelnen Server, Hintergrundsysteme oder Dienste enthalten.



    2. Fehlermeldungen
    Fehlermeldungen sind ein wesentlicher Bestandteil des Bugtrackers. Sie geben den Nutzern die Möglichkeit Fehlverhalten innerhalb eines Dienstes zu melden.
    2.1 Erkennen eines Fehlers
    Eine Fehlermeldung sollte nur erstellt werden, wenn es sich mit großer Wahrscheinlichkeit um einen Fehler des Dienstes handelt.
    Folgende Fragen kann man sich stellen um einen Fehler als solchen zu identifizieren:

    • Funktioniert etwas ohne eine angekündigte Änderung anders als bisher?
    • Tritt der Fehler bei gleicher Benutzung auch bei anderen Personen auf?
    • Tritt der Fehler spontan oder nur unter bestimmten Faktoren auf?

    Wenn man eine Fehlfunktion nicht zweifelsfrei als solche identifizieren kann besteht die Möglichkeit einen Beitrag im Forum (Hilfe) zu erstellen.
    2.2 Melden eines Fehlers (Eventuell mit Screenshots für die einzelnen Punkte?)
    Bevor ein Fehler gemeldet wird, sollte zuerst überprüft werden ob er bereits bekannt ist.
    Hierzu navigiert man zuerst in die Kategorie in die der Fehler auftritt und wählt, falls bekannt das zuständige System aus.
    Innerhalb dieser Ansicht gibt es nun den Button "Fehler melden", durch klicken öffnet sich die Eingabemaske für einen neuen Fehler.

    • Wenn die aktuelle Produktversion bekannt ist kann man diese im Dropdown auswählen, sollte die Version nicht bekannt sein kann auch Keine Angabe ausgewählt werden.
    • Im Feld Titel kann man eine kurze, möglichst treffende Beschreibung eingegeben.
    • Das Feld Zusammenfassung muss nicht genutzt werden, bei besonders komplexen Fehlern empfiehlt es sich jedoch den Fehler hier in circa 3 Sätzen zu beschreiben.
    • Im Feld Fehlermeldung kann eine eventuell aufgetretene Fehlermeldung des Systems eingetragen werden.
    • Unter Reproduzierbarkeit kann, wenn bekannt, der betreffende Button ausgewählt werden. Je nach Auswahl erscheint ein zusätzliches Textfeld, dies sollte ebenfalls ausgefüllt werden.
    • Im Feld Nachricht kann man nun eine detaillierte Beschreibung des Fehlers und eventuell zusätzliche Fragen eintragen.

    2.2 Bearbeitung von Fehlern
    Fehler werden immer schnellstmöglich, jedoch nicht immer chronologisch bearbeitet. Dabei durchlaufen sie im Wesentlichen folgende Phasen:

    • Nicht bestätigt: Ein neu erstellter Fehler gilt zuerst immer als nicht bestätigt, bis er von anderen Nutzern oder einem Teammitglied bestätigt wurde.
    • Nachdem der Fehler von einem Teammitglied eingestuft wurde kann er entweder als Kein Fehler, Duplikat oder Bestätigt eingestuft werden. In den ersten beiden Fällen ist die Bearbeitung nun beendet.
    • Ein bestätigter Fehler wird nun von den Entwicklern betrachtet und bei Arbeitsbeginn auf den Status In Arbeit gesetzt.
    • Wenn der Fehler behoben ist wird sein Status auf Behoben gesetzt und ein Meilenstein für die Implementation des Fixes definiert.

    3. Vorschläge
    Vorschläge können genutzt werden um Ideen an die Entwickler heranzutragen.
    3.1 Vorschlag einreichen (Eventuell mit Screenshots für die einzelnen Punkte?)
    Hierzu navigiert man zuerst in die Kategorie in der ein Vorschlag eingereicht werden soll und wählt, falls bekannt das zuständige System aus.
    Innerhalb dieser Ansicht gibt es nun den Button "Vorschlag einreichen", durch klicken öffnet sich die Eingabemaske für einen neuen Vorschlag.

    • Im Feld Titel kann eine kurze, möglichst treffende Beschreibung eingegeben werden.
    • Im Feld Nachricht sollte man den Vorschlag möglichst exakt beschreiben.

    3.2 Bearbeitung von Vorschlägen

    • Nicht bestätigt: Ein neu erstellter Vorschlag gilt zuerst immer als nicht bestätigt, bis er weiter bearbeitet wird.
    • Nachdem der Vorschlag von einem Teammitglied eingestuft wurde kann er entweder als Abgelehnt, Duplikat, Warten auf Feedback oder Geplant eingestuft werden. In den ersten beiden Fällen ist die Bearbeitung nun beendet. Im dritten Fall wird dieser Schritt nach angemessener Zeit wiederholt.
    • Ein geplanter Vorschlag wird nun von den Entwicklern betrachtet und bei Arbeitsbeginn auf den Status In Umsetzung gesetzt.
    • Wenn der Vorschlag implementiert ist wird sein Status auf Umgesetzt gesetzt und ein Meilenstein für die Implementation des neuen Features definiert.

    4. Meilensteine
    Meilensteine werden genutzt um Systeme zu versionieren. Genutzt wird hierbei das Semantic Versioning (http://semver.org/).
    Innerhalb eines Meilensteins befindet sich eine Auflistung aller behobenen Fehler und umgesetzten Vorschlägen.


    5. Wie kategorisiere ich richtig?
    Das Kategorisieren von Fehlern und Vorschlägen ist besonders wichtig, da so schneller reagiert werden kann.
    Daher sollte es in etwa wie nachfolgend beschrieben ablaufen:

    • Wenn bekannt ist welcher Dienst betroffen ist, kann dieser direkt ausgewählt werden.
    • Ist der genaue Dienst nicht bekannt, kann auch ein anderer eventuell ebenfalls passender Dienst gewählt werden.
    • Sollte kein passender Dienst gefunden werden, kann zuerst ein Eintrag im Forum (Hilfe) gestartet werden.

    [hr][/hr]
    Werde am Wochenende weiterschreiben, falls ein Text dieser Art fürs Wiki gewünscht wäre.
    @_Slik besteht Bedarf / Interesse, natürlich in deutlich ausführlicher. Besonders in Richtung was passiert mit Fehlern / Vorschlägen nach deren Einreichung? Und natürlich auch in Richtung Screen-Footage, Milestones, etc.
    @Scrayos hat angemerkt, dass ich noch einen "Misc Info" Bereich ganz unten anfügen sollte, in dem die Thematik einordnen eines Fehlers/Vorschlags erklärt wird.
    Gruß
    Prof.Logout | Marco

    You think focusing is about saying "Yes." No. Focusing is about saying "No." And when you say "No," you piss off people.

    7 Mal editiert, zuletzt von ProfessorLogout ()

  • Hey,
    erst einmal möchte ich mein Lob aussprechen, deine Einsatzbereitschaft in letzter Zeit ist bemerkenswert :D


    Die Idee finde ich super und auch der Text bis jetzt ist tadellos, wenn du weiter schreiben möchtest wäre das ein willkommenes Angebot.
    Bilder kannst du mir im Forum schicken, sobald der Text fertig ist mach ich dann einen Wiki Beitrag daraus.


    Kevin / _Slik

  • N'Abend,


    habe es so weit (bis auf Screenshots) fertig.
    @ProfessorDevil hat auch gerade schon Korrektur gelesen und mir verflucht viel umgeschmissen...


    EDIT:
    @Scrayos hat angemerkt, dass ich noch einen "Misc Info" Bereich ganz unten anfügen sollte, in dem die Thematik einordnen eines Fehlers/Vorschlags erklärt

    You think focusing is about saying "Yes." No. Focusing is about saying "No." And when you say "No," you piss off people.

  • @Scrayos so angenehm?

    You think focusing is about saying "Yes." No. Focusing is about saying "No." And when you say "No," you piss off people.