# Humans vs Zombies

## Project management
We gaan werken volgens [Kanban](https://blog.trello.com/kanban-data-nave). In het kort: kanban is een manier van een project managen. Je maakt niet van te voren een uitgebreide planning, maar je hebt een takenlijst die gedurende het project wordt gevuld. Taken komen op een bord terecht die de status weergeeft. Het bord ziet er ongeveer zo uit:

| Todo | Dev | Review | Test | Closed |
| ---- | --- | ------ | ---- | ---- |
| | Taak 3 | Taak 2 | | Taak 1 |
| Taak 4 | | | | |
| Taak 5 | | | | |
| Taak 6 | | | | |

Ons bord is op [Gitlab](https://gitlab.com/groups/noroff2021nederland/-/boards) te vinden. Als je een taak oppakt, dan drag je die taak van de kolom Todo naar Dev en assign je jezelf aan die taak.

### Issues
Als je een issue toevoegt schrijf de volgende dingen op:
- Titel
- Checkboxes met sub taken (- [ ] sub taak)
- Labels

#### Labels
Categorie:
- api
- db
- documentation
- frontend
- misc
- performance
- security

Status:
- todo
- development
- review
- test
- closed

Prioriteit:
- HIGH
- MEDIUM
- LOW

Prioriteit wordt gebaseerd op hoe groot de impact is en hoe groot de kans is dat het voorkomt. Een belangrijke feature die 1x per 100 games gebruikt wordt heeft dus een LOW prioriteit. Een bug met een kleine impact maar hoge frequentie krijgt dan een MEDIUM prioriteit.

## Werkwijze
Inprincipe pak je taken van het kanban bord zelf op. Als je ergens tegenaan loopt of je je verveelt kan je iemand vragen voor pair programming.

Documenteer je code.

Test waar mogelijk al je code met unit testen
- Angular: unit testen met ng test
- API: c# unit test met mock data

## Planning
Elke dag om 09:00 een daily standup. Maandag om 09:00 review van de afgelopen week. Verder ben je vrij je dag in te delen.

### Daily standup
1. Wat heb je gister gedaan?
2. Wat ga je vandaag doen?
3. Is er iets dat je blokkeerd?

### Globale planning
Vrijdag 25 juni code lock.
Vrijdag 25 juni presentatie klaar.

## Git
Er zijn drie verschillende soorten branches: master, development en je eigen werk branch.
- Je werk doe je op een eigen nieuwe branch voor elke taak (<author>_<branch-name> bijvoorbeeld: devin_setup-frontend)
- Maak je commits zo klein mogelijk, dan is het makkelijk om te reviewen voor iemand anders
- Maak een merge request met hooguit een paar commits, zodat het makkelijk te reviewen is voor iemand anders
- Merge je code met de development branch als die is goedgekeurd
- Verhelp eventuele conflicten
- Zodra de taak helemaal is goedgekeurd en afgerond kan de development branch met de master branch gemerged worden

### Reviewen van een Merge Request (MR)
Voeg comments toe op de regels als:
1. Iets niet duidelijk is
2. Je denkt dat iets beter kan
3. Suggesties

Keur een merge request alleen af als er bugs gaan ontstaan als de code wordt gemerged met de development branch. Je kan de MR goedkeuren als de code prima is, of als je alleen kleine vragen of suggesties hebt. Je kan erop vertrouwen dat de indiener de wijzigingen aanbrengt.

Als je ergens over twijfelt neem contact op met de indiener.

### Review checklist
Voer deze checklist uit voor je een MR indient en als je een MR van iemand anders gaat reviewen.
- [ ] Documentatie
- Summary tags
- Inline comments
- [ ] Code conventies
- [ ] Testen
- Alles wat mogelijk is
- [ ] Leesbare code

## Design
Mobile first. Gebruik de dev tools om de mobiele weergave te zien.