Developer Guide

The Non-Negotiables

• Main line should work and be documented.
• Protect main (pull-request only! We only accept our own pull-request in case of emergency).
• Automated end-to-end on any push to any feature branch and on merge to main.
• Prioritise reviewing our team-mates' pull-requests.
• Wait for review and then merge ourselves with squash.

Collaboration Guide

Choosing Issues to Work On

• People assign themselves to tickets. When in doubt, do not assign a ticket to someone.
• Feel free to select the issues you want to work on
  • Leave a comment that you are working on it, and update as need be
  • Preferably work on one issue and close it, before taking on extra ones
• Keep track of how long it took to fix it, so similar issues in the future can have estimates for implementation

About the Code Reviews

Review the code more in depth AT LEAST when

• Before you merge feature to main
• When a bug is fixed on main before its hotfix/bugfix branch is merged
• When a release is made by merging the current state of the development branch to main

Code Reviewing Guideline

• If there are multiple reviewers for a single issue, one of them will be the main one
• If you would like to request a specific thing to be changed, use the suggest a change feature

• When they are created like this:
  • Don't have to neccessarily approve or disapprove the pull request
  • Straight forward approved PR's - LGTM
  • Straight forward rejected PR's - Something has to be still fixed or discussed
  • If there are no rejections, the main reviewer will merge the PR and delete the feature branch
    • Deleting is the job of the reviewer not the author

A More about Code Reviews

• Reviewing more often in smaller chunks is better
• A main reviewer shold be allocated at some point
• Don't write novels when reviewing code
• The reviewer is not the one who should be doing the testing, this is on the author to do

I quite like this code review guideline, and I highly recommend reading through it.