Workflow

Een vooraf overeengekomen workflow bespaart veel vragen en gedoe.

Project board

Handig om to-do's overzichtelijk en up-to-date online te hebben. We hebben een project board aangemaakt binnen deze repo zodat we een beetje in de gaten kunnen houden waar we staan en dat we geen dingen vergeten zonder 't te documenteren.

Issues

Issues zijn basically de to-do's voor dit project. Als er iets gefixt moet worden (feature, bugfix, refactoring, docs etc) openen we een issue met in de titel de to-do. We hebben ook een aantal templates gemaakt voor de issues die anderen bij ons kunnen inschieten tijdens de Peer Reviews. Die templates gebruiken we dan zelf ook wanneer we een ander moeten reviewen. Voor onze to-do's gebruiken we eigenlijk geen template aangezien we ze zo kort mogelijk willen houden; de titel zou voldoende moeten zijn.

Labels

We hebben labels gebruikt om overzicht te creëren betreft wat voor soorten taken we hebben; zo kunnen we ook onze planning hierop aan laten sluiten.
Ikzelf doe bijvoorbeeld het liefst documentatietaken achter elkaar, of codeertaken achter elkaar, en we hebben allemaal soms nogal wat moeite om van focus te switchen dus dit helpt wel met prioriteren.

Milestones

Deze assignment bestond uit een deel 'werken met enquêtedata', en een deel 'werken met conceptdata'.
We hebben dan ook aparte milestones aangemaakt hiervoor zodat we eerst het een zouden afmaken voor we aan het ander beginnen.

Branches

Voor het adden van features maken we een aparte branch aan met feat/ , en als ik specifiek voor refactoren ga maken we een branch aan met refactor/. Readme-updates of het uploaden van images voor de wiki/readme doen we ook gewoon op de main branch.
Daarover gesproken; we hebben onze main branch main genoemd nadat ik aangekaart zag worden dat master branch best wel een rukbenaming is gezien de history met die benaming; kleine moeite om 'm dan te hernoemen. En zeg nou zelf: als je met branches werkt, is het toch sowieso logischer dat ze van een main of trunk afkomen?

We werken overigens in branches omdat het je forceert te focussen op het ene ding waar je mee bezig bent (waar velen moeite mee hebben lol, het scheelt je merge conflics en het is handig om vast aan gewend te raken voor verdere teamprojecten of werk. Het is ook fijn als je een feature gewoon af kan sluiten zo.

Pull Requests

De branches mergen we met onze main branch middels een pull request; normaal gesproken zou Netlify dan ook gelijk moeten checken of ik dan niet iets breek maar we hebben Netlify niet de goede build-commands doorgegeven dus vandaar dat je nu allemaal kruisjes ziet. Momenteel deployen ik toch via Github Pages of Herokuapp dus maakt niet zo veel uit verder.

Verder in dit project kwamen we er ook achter dat Netlify (zonder serverless shizzle) ook eigenlijk alleen maar static sites deployed, dus zijn we weer voor good ol' Heroku gegaan.

Commits

Commits proberen we te doen volgens deze guidelines.
Mostly betekent dat dat we alles in tegenwoordige tijd doen, en ervoor zetten waar het over gaat (feat:, refactor:, fix: etc.).
'Commit early, commit often.' --> we proberen zo veel mogelijk single-purpose commits te doen, en zo veel mogelijk. Is ook leuk voor je graph. Is minder leuk als je commits van je backupaccount niet meegeteld worden in je graph of als je dingen in GitLab doet.