Workflow

CodingGuidelines.md

Coding style

We mainly use the coding conventions from F# Component Design Guidelines.

The formatting style should be consistent as much as possible throughout the code base.

Git.md

1. Create a new feature

1. Get the latest updated master branch

2. Branch from it

> git checkout -b feature/my-new-feature

3. Code

2. Sync the working branch, after master was updated

We most exclusively use the rebase feature (not the merge feature):

1. Get the latest updated master branch

> git fetch origin
> git checkout master
> git pull

2. Switch to your local working branch

> git checkout feature/my-new-feature

3. Rebase your local working branch onto master (interactive mode if easier)

> git rebase -i master

4. Solve the possible conflicts

3. Syncing the working branch after it has been pushed to the depot

1. Follow the same instructions as in the scenario 2.

2. Force push the local branch to the remote branch

> git push origin -f

WorkProcess.md

Planning our "sprints"

Before starting to work, we will meet to talk and plan our strategy (modules to work on, architectural changes...), in a way that we don't work on the same files & our changes don't conflict together.

Cost estimates

The following concerns should be taken into account when costing features:

• Unit testing
• Refactoring
• Localization
• Manual testing

Coding & merging habits

• ALL: Each unit of work will have to be in a separate branch
• ALL: Each unit of work will have to go through a review & pull request before merging
• ALL: Keep units of work small so that they're easy to review/understand, and to minimize integration conflicts
• ALL: Review each other's pull requests
• ALL: Critical code should be properly unit tested
• LEAD DEV: Approves & merges the pull request to the master branch

Before PROD

• We should perform some basic manual testing on both iOS and Android.
• Unit tests should all be green, unless explicit agreement to make an exception.