5 files changed, 101 insertions, 3 deletions
diff --git a/doc/SPI-LCD-driver.md b/doc/SPI-LCD-driver.md
index 3c33c258..f787aab7 100644
--- a/doc/SPI-LCD-driver.md
+++ b/doc/SPI-LCD-driver.md
@@ -24,17 +24,17 @@ As I said in the introduction, the datasheet will be your bedside book during yo
 
 The schematic of your board (the Pinetime schematics in this case) will also be very important, as you'll need to know how the LCD controller is physically connected to the MCU.
 
-How to read the datasheet? I recommand to read it from the beginning to the end (no joke) at least once. You certainly do not need to read everything in details, but it's good to know what information is available and where in the document. It'll be very useful during the developpment phase.
+How to read the datasheet? I recommend to read it from the beginning to the end (no joke) at least once. You certainly do not need to read everything in details, but it's good to know what information is available and where in the document. It'll be very useful during the development phase.
 You'll want to read some part with more attention :
 - Data color coding in 4-Line Serial Interface : how to send the pixel to be display to the controller
-- Display Data Ram : how is the memory organised
+- Display Data Ram : how is the memory organized
 - Power On/Off sequence
 - System function commands : all the commands you can send to the controller.
 
 ## One Pixel at a time
 
 
-## Bulk transfert
+## Bulk transfers
 
 ## DMA
 
diff --git a/doc/branches.md b/doc/branches.md
new file mode 100644
index 00000000..0fb8316d
--- /dev/null
+++ b/doc/branches.md
@@ -0,0 +1,12 @@
+# Branches
+The branching model of this project is based on the workflow named [Git flow](https://nvie.com/posts/a-successful-git-branching-model/).
+
+It is based on 2 main branches:
+ - **master** : this branch is always ready to be reployed. It means that at any time, we should be able to build the branch and release a new version of the application.
+ - **develop** : this branch contains the latest development that will be integrated in the next release once it's considered as stable.
+
+New features should be implemented in **feature branches** created from **develop**. When the feature is ready, a pull-request is created and it'll be merge into **develop** when it is succesfully reviewed and accepted.
+
+To release a new version of the application, when develop is considered stable, a **release** branch is created from **develop**. This can be considered as a *release candidate* branch. When everything is OK, this release branch is merged into **master** and the release is generated (a tag is applied to git, the release note is finalized, binaries are built,...) from **master**.
+
+Git flow also supports the creation of **hotfix** branches when a bug is discovered in a released version. The **hotfix** branch is created from **master** and will be used only to implement a fix to this bug. Multiple hotfix branches can be created for the same release if more than one bugs are discovered.
+\ No newline at end of file
diff --git a/doc/contribute.md b/doc/contribute.md
new file mode 100644
index 00000000..53c6ac06
--- /dev/null
+++ b/doc/contribute.md
@@ -0,0 +1,24 @@
+# How to contribute?
+## Report bugs
+You use your Pinetime and find a bug in the firmware? [Create an issue on Github](https://github.com/JF002/Pinetime/issues) explaining the bug, how to reproduce it, the version of the firmware you use...
+## Write and improve documentation
+Documentation might be incomplete, or not clear enough, and it is always possible to improve it with better wording, pictures, photo, video,... 
+
+As the documentation is part of the source code, you can submit your improvements to the documentation by submitting a pull request (see below).
+## Fix bugs, add functionalities and improve the code
+You want to fix a bug, add a cool new functionality or improve the code? See *How to submit a pull request below*.
+## Spread the word
+Pinetime is a cool open source project that deserves to be know. Talk about it around you, on social networks, on your blog,... and let people know that we are working on an open-source firmware for a smartwatch!
+
+# How to submit a pull request ?
+Your contribution is more than welcome! 
+
+If you want to fix a bug, add a functionality or improve the code, you'll first need to create a branch from the **develop** branch (see [this page about the branching model](./branches.md)). This branch is called a feature branch, and you should choose a name that explains what you are working on (ex: "add-doc-about-contributions"). In this branch, try to focus on only one topic, bug or feature. For example, if you created this branch to work on the UI of a specific application, do not commit modifications about the SPI driver. If you want to work on multiple topics, create one branch per topic.
+
+When your feature branch is ready, make sure it actually works and do not forget to write documentation about it if necessary.
+
+Then, you can submit a pull-request for review. Try to describe your pull request as much as possible: what did you do in this branch, how does it work, how is it designed, are there any limitations,... This will help the contributors to understand and review your code easily.
+
+Other contributors can post comments about the pull request, maybe ask for more info or adjustements in the code.
+
+Once the pull request is reviewed an accepted, it'll be merge in **develop** and will be released in the next release version of the firmware.
+\ No newline at end of file
diff --git a/doc/filesInReleaseNotes.md b/doc/filesInReleaseNotes.md
new file mode 100644
index 00000000..e9dadb24
--- /dev/null
+++ b/doc/filesInReleaseNotes.md
@@ -0,0 +1,56 @@
+# Using the releases
+For each new *stable* version of Pinetime, a [release note](https://github.com/JF002/Pinetime/releases) is created. It contains a description of the main changes in the release and some files you can use to flash the firmware in your Pinetime.
+
+This page describes the files from the release notes and how to use them.
+
+**NOTE :** the files included in different could be different. This page describes the release note of [version 0.7.1](https://github.com/JF002/Pinetime/releases/tag/0.7.1), which is the version that'll probably be pre-programmed at the factory for the next batch of Pinetime devkits.
+
+## Files included in the release note
+
+### Standalone firmware
+This firmware is standalone, meaning that it does not need a bootloader to actually run. It is intended to be flash at offset 0, meaning it will erase any bootloader that might be present in memory.
+
+ - **pinetime-app.out** : Output file of GCC containing debug symbols, useful is you want to debug the firmware using GDB.
+ - **pinetime-app.hex** : Firmware in Intel HEX file format. Easier to use because it contains the offset in memory where it must be flashed, you don't need to specify it.
+ - **pintime-app.bin** : Firmware in binary format. When programming it, you have to specify the offset (0x00) in memory where it must be flashed.
+ - **pinetime-app.map** : Map file containing all the symbols, addresses in memory,...
+ 
+**This firmware must be flashed at address 0x00 in the main flash memory**
+
+### Bootloader
+The bootloader  is maintained by [lupyuen](https://github.com/lupyuen) and is a binary version of [this release](https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v4.1.7).
+
+ - **bootloader.hex** : Firmware in Intel HEX file format.
+ 
+ **This firmware must be flashed at address 0x00 in the main flash memory**
+
+
+### Graphics firmware 
+This firmware is a small utility firmware that writes the boot graphic in the external SPI flash memory. You need it if you want to use the [bootloader](../bootloader/README.md).
+
+ - **pinetime-graphics.out** : Output file of GCC containing debug symbols, useful is you want to debug the firmware using GDB.
+ - **pinetime-graphics.hex** : Firmware in Intel HEX file format. Easier to use because it contains the offset in memory where it must be flashed, you don't need to specify it.
+ - **pintime-graphics.bin** : Firmware in binary format. When programming it, you have to specify the offset (0x00) in memory where it must be flashed.
+ - **pinetime-graphics.map** : Map file containing all the symbols, addresses in memory,...
+ 
+**This firmware must be flashed at address 0x00 in the main flash memory**
+
+### Firmware with bootloader
+This firmware is intended to be used with our [MCUBoot-based bootloader](../bootloader/README.md).
+
+ - **pinetime-mcuboot-app-image.hex** : Firmware wrapped into an MCUBoot image. This is **the** file that must be flashed **@ 0x8000** into flash memory. If the [bootloader](../bootloader/README.md) has been successfully programmed, it should run this firmware after the next reset.
+
+The following files are not directly usable by the bootloader:
+
+ - **pinetime-mcuboot-app.bin** : Output file of GCC containing debug symbols, useful is you want to debug the firmware using GDB.
+ - **pinetime-mcuboot-app.hex** : Firmware in Intel HEX file format. 
+ - **pinetime-mcuboot-app.bin** : Firmware in binary format. 
+ - **pinetime-mcuboot-app.map** : Map file containing all the symbols, addresses in memory,...
+
+### OTA (Update the firmware Over-The-Air)
+Once the bootloader and application firmware are running, it is possible to update the current firmware or even replace it with another firmware **that uses the same bootloader based on MCUBoot**.
+
+**NOTE :** Use this file **only** if you programmed our [MCUBoot-based bootloader](../bootloader/README.md). This file is not compatible with other bootloaders like the one that is based on the closed source NRF SoftDevice !
+
+ - **pinetime-app-dfu.zip** : This is the file you must provide toNRFConnect to update the firmware over BLE.
+
diff --git a/doc/versioning.md b/doc/versioning.md
new file mode 100644
index 00000000..b08af714
--- /dev/null
+++ b/doc/versioning.md
@@ -0,0 +1,6 @@
+# Versioning
+The versioning of this project is based on [Semantic versionning](https://semver.org/) :
+
+ - The **patch** is incremented when we fix a bug on a **released** version (most of the time using a **hotfix** branch).
+ - The **minor** is incremented when we release a new version with new features. It corresponds to a merge of **develop** into **master**.
+ - The **major** should be incremented when a breaking change is made to the application. We still have to define what is a breaking change in the context of this project. For now, I suggest that it stays **0** until we have a fully functionning firmware suited for the final user.
+\ No newline at end of file