Arbeitsvorrat Sentry

Hier eine kurze Beschreibung, wie ihr vorgehen könnt um Issues in Sentry in einer sinnvollen Reihenfolge abzuarbeiten:

Wichtige Issues identifizieren

Ich würde vorschlagen, Issues auf diesen drei Achsen anzugehen:

• Sortieren nach Häufigkeit (Anzahl Events) (Dies sind Issues, die Häufig auftreten, und daher wahrscheinlich viele unserer Kunden betreffen)
  Query: sort=freq

• Sortieren nach Last Seen (Issues die fast sicher noch nicht gelöst sind, sonst würden sie nicht mehr auftreten) Query: last seen

• Issues die in einem bestimmten Release das erste Mal aufgetreten sind. (Von jüngstem zu älteren Releases abarbeiten - Fehler die erst vor kurzem eingebaut wurden, sind i.d.R. auch einfacher wieder auszubauen und man erinnert sich eher noch daran, wo vor kurzem etwas angepasst wurde)

Queries:

• 2018.4.0.dev0

• 2018.3.6.dev0

• 2018.3.5.dev0

• 2018.3.5 (Aktueller Relrease bei SG)

• 2018.3.4

• 2018.3.2

• 2018.3.1

• 2018.3.0.dev0

• 2017.6.8 (Aktueller Release bei ZG)

Issue triagieren

• ❗️ Zuerst schauen, ob die Sentry Issue schon Kommentare und/oder eine verlinkte GitHub issue hat

• Die Issue sich selbst assignen

• Kurz eine Suche durchführen, ob es vielleicht schon eine Issue gibt die resolved ist, aber fälschlicherweise nicht zusammen gruppiert wurde. Falls ja, und definitiv klar ist, dass es sich um das selbe Problem handelt (und auch dieselbe Lösung), diese issues mergen. Im Zweifelsfall bitte nachfragen, Sentry events können nicht mehr unmerged werden!

• Herausfinden, was genau für ein Problem besteht

• Falls das Problem durch eine Anpassung im Code (commit in og.core) gelöst werden kann/muss:

  • Identifizieren, wie das Problem reproduziert werden kann/konnte (steps to reproduce)
  • Nachdem klar ist, wie das Problem reproduziert werden kann:
    • Prüfen, ob das Problem im aktuellen master ebenfalls noch reproduziert werden kann

• Falls das Problem noch besteht, GitHub issue (via Button in Sentry) mit "steps to reproduce" erfassen

• Falls nicht: PR ausfindig machen welcher das Problem gelöst hat, in die Sentry issue kommentieren (s.U.) und Issue auf die entsprechende Version resolven.

• Issue unassignen (ihr must nicht zwangsläufig die issue gleich lösen, ggf. kann dies auch jemand anders) und Erkenntnisse als Kommentar hinterlassen.

Issue lösen

• PR mit dem Fix erstellen, und die erstellte Issue closen. Nachdem der PR gemerged ist, Sentry issue auf den entsprechenden Release resolven, PR in Kommentar hinterlassen.

Bitte beim resolven von Issues versuchen, ein einheitliches Schema verwenden:

Fixed in https://github.com/4teamwork/opengever.core/pull/xyz (2018.3.0)