Issues

Issues er jeres opgaveliste på GitHub — fra kundens bug til sprint-feature, helt til lukket via pull request og release.

Hvorfor bruger vi issues?

Uden issues forsvinder opgaver i chatten. Med issues har I struktur, ansvar og sporbarhed hele vejen fra idé til leverance.

  • Fælles opgaveliste — Issues er teamets todo-liste på GitHub — alle kan se hvad der skal laves, hvem der arbejder på det, og hvad status er.
  • Dialog med kunden — En bug fra kunden bliver til et issue med beskrivelse, prioritet og opfølgning — ikke en løs besked i chatten.
  • Sporbarhed til kode — Via "Closes #42" i PRs kan I følge en ændring fra opgave → kode → release. Perfekt til sprint og dokumentation.
  • Sprint-planlægning — Issues kan lægges på et GitHub Project board med kolonner som Todo, In Progress og Done — jeres digitale sprint-board.

Sådan arbejder vi med issues

Vaner der gør sprint og samarbejde med kunden forudsigeligt.

  • Ét issue per opgave

    Opdel store features i mindre issues. "Byg hele appen" er ikke et issue — "Tilføj login-side" er.

  • Beskriv så andre forstår

    En god issue har titel, beskrivelse, steps to reproduce (for bugs) og acceptance criteria (for features).

  • Tildel ansvar

    Assign issue til den der arbejder på det. Så undgår I at to tager samme opgave.

  • Luk via PR — ikke manuelt

    Brug "Closes #12" i PR-beskrivelsen så issue lukkes automatisk ved merge. Det holder boardet opdateret.

Issue → kode — visuelt

Følg issue #42 fra oprettelse til lukket via branch, PR og merge på main.

Klik på trinene og se issue #42 koblet til branch, PR og main

issuebranchlukket

Issue oprettet

Bug eller feature dokumenteret som issue #42 på GitHub.

Issue-livscyklus

Fra oprettelse til lukket via PR — klik gennem trinene og følg issue #42.

Klik på trinene og se issue #42 fra oprettelse til lukket via PR

#42

Login fejler når e-mailfelt er tomt

Openbug
## Beskrivelse Login fejler når e-mailfelt er tomt. ## Steps to reproduce 1. Gå til /login 2. Lad e-mail stå tom 3. Klik "Log ind"

Ny issue på GitHub

GitHub → Issues → New issue. Vælg skabelon hvis I har en, skriv titel og beskrivelse. Tilføj labels (bug, enhancement) og milestone (sprint).

💡 Gode titler er specifikke: "Fix: validering af e-mail" frem for "Bug i form".

Issue-skabeloner

Bug, feature og chore har forskellig struktur. Vælg type og brug skabelonen.

Vælg issue-type og se skabelon til titel og beskrivelse

Noget virker ikke som forventet — fejl, crash, forkert adfærd.

Forhåndsvisning

Login fejler når e-mailfelt er tomt

## Beskrivelse Kort hvad der går galt. ## Steps to reproduce 1. Gå til /login 2. Lad e-mail stå tom 3. Klik "Log ind" ## Forventet adfærd Valideringsfejl vises. ## Faktisk adfærd App crasher / ingen fejlbesked. ## Relateret Sprint 3 · fundet af kunde

Kobl issues til PRs

Keywords i PR-beskrivelsen styrer om issue lukkes automatisk ved merge.

Dårlige vs. gode issues

Kvalitet i issues sparer tid i review og sprint.

Undgå
Bug
Gør i stedet
Login fejler når e-mailfelt er tomt

Titlen skal sige hvad der er galt — ikke bare "Bug".

Undgå
Fix login
Gør i stedet
Som bruger vil jeg se fejlbesked ved ugyldig e-mail

Features beskrives som user stories med acceptance criteria.

Undgå
(tom beskrivelse)
Gør i stedet
Steps to reproduce + forventet/faktisk adfærd

Uden steps kan ingen anden genproducere buggen.

Undgå
Issue lukkes manuelt uden PR
Gør i stedet
Closes #42 i merged PR

Automatisk lukning sikrer sporbarhed fra issue til kode.


Fra issue til release

Issues er startpunktet i jeres workflow — koblet til branch, PR, merge og release.

Klik på hvert trin for at se forklaring og kommandoer

Opret opgave

Issues er udgangspunktet — bug, feature eller chore dokumenteres før kode skrives.

Trin-for-trin guide

Sådan opretter du et issue og lukker det via pull request.

0 / 5 fuldført

Vælg type (bug/feature/chore). Udfyld beskrivelse så en holdkammerat kan tage over. Tilføj labels og sprint-milestone hvis I bruger det.

GitHub
# GitHub:
# Issues → New issue
# Titel: fix(auth): login fejler ved tom e-mail
# Label: bug
# Milestone: Sprint 3

Test din viden

Svar på spørgsmålene for at tjekke om du har styr på GitHub Issues.

Hvad er hovedformålet med GitHub Issues?

Hvordan lukkes et issue automatisk ved merge?

Hvad bør en bug-issue minimum indeholde?

Hvorfor bruge issue-nummer i branch-navn (fx fix/42-login)?

Hvad er forskellen på "Closes #42" og "Relates to #42"?