sprintDoc

GitHub-Support als Issue-Tracker (JIRA-Ersatz)

requirement_pattern
StatusKonzeption/Idee
Geplante Stunden50
Korrespondierendes Epic

SPR-292

Korrespondierendes FeatureGithub-support

Grund und Umfang der Spezifikation

  • Es wird überlegt, nicht nur JIRA als Issue-Tracker einzubinden sondern alternativ auch GitHub

Produkt-/Projekt-Kontext

  • Dies ist besonders für OpenSource-Projekte sinnvoll, da diese sowieso oftmals auf GitHub ihre Repos hosten
  • Die Komplexität der Nutzung verschiedenster Systeme würde sich reduzieren, da GitHub zumindest eingeschränkt auch Issue-Tracker-Features anbietet

Annahmen

  • GitHub ist kostenfrei, es sei denn jemand möchte seine Repos privat schalten

Einschränkungen / Bedingungen

  • Funktionsumfang von GitHub ist nicht so ausgereift wie bei JIRA

GitHub-Informationen in SprintDoc

Felder der Issues:

Feld Jira GitHub GitLab
Summary/Title :yes: :yes: :yes:
Beschreibung :yes: :yes: (original Post) :yes: (original Post)
Type :yes: :no: :no:
Status :yes: :yes: (nur open/closed) :yes: - :?: Wie wirkt sich die Position auf dem Board aus?
Labels :yes: :yes: :yes:
priority :yes: :no: :no:
duedate :yes: :no: :yes:
versions :yes: :no: :no:
updated :yes: :yes: :yes:
Epic not yet :no: :no:
Milestone :no: :yes: :yes:
Confidential :no: :no: :yes:

Herausforderungen

  • GitHub hat keinen Issue-Typ, sondern es werden Labels auch für diesen Zweck verwendet.
    • Diese müssen wir auf den Issue-Typ Mappen
    • Liste von Labels die als Status gemappt werden sollen: Bug, Feature, Enhancement?
  • Ähnlich könnte mit Prioritäten verfahren werden

Abhängigkeiten

» User accounts are intended for humans, but you can give one to a robot, such as a continuous integration bot, if necessary.

Existing Bots:

Status von Pull-Requests:

sonstiges: Best practices for integrators