Merge branch '23-fix-formatting-issue-in-contributing-md' into 'dev'

Resolve "Fix formatting issue in CONTRIBUTING.md"

Closes #23

See merge request nodes/rust/duniter-rs!15

CONTRIBUTING.md

@@ -14,8 +14,7 @@ Please note we have a specific workflow, please follow it in all your interactio
 - Please use tags to specify feature domains and concerned crates.
 - Never contribute to a branch whose issue has not been assigned to you! If the contributor make a
   `git rebase` your commit will be lost !
-- Before you push your commit: 
-  1.  Apply `rustfmt`. Only formatted code will be accepted, and gitlab-ci will make sure it is ok.
+- Use `rustfmt`. Only formatted code will be accepted, and gitlab-ci will make sure it is ok.
     Some exceptions are accepted such as long raw strings.
 
     `rustfmt` is a tool applying Rust idiomatic code style to your files automatically.
@@ -43,7 +42,7 @@ Please note we have a specific workflow, please follow it in all your interactio
     > If you switch from 1.23 to 1.24, uninstall `rustfmt` from cargo and install it back with
     > `rustup`
 
-  1.  Use `clippy`.
+- Use `clippy`.
 
     `clippy` is a linting tool scanning your code to find common mistakes or bad code.
 
@@ -58,7 +57,7 @@ Please note we have a specific workflow, please follow it in all your interactio
     cargo +nightly clippy
     ```
 
-  1.  Document your code and avoid any unsafe feature.
+- Add documentation in your code and avoid any unsafe feature.
 
     Each create should contain in its root file
 
@@ -71,8 +70,8 @@ Please note we have a specific workflow, please follow it in all your interactio
     It forces you to write documentation for any public code and prevent you from using unstable
     or unsafe code.
 
-  1.  Write unit tests, and verify that they **all** pass.
-  1.  Made a git rebase to make your history clean.
+- Write unit tests, and verify that they **all** pass.
+- Use git rebase to make your history clean.
 
     ```bash
     # Make an alias
@@ -83,15 +82,13 @@ Please note we have a specific workflow, please follow it in all your interactio
 
 ## Merge Process
 
-1.  Ensure any install or build dependencies are removed before the end of the layer when doing a 
+- Ensure any install or build dependencies are removed before the end of the layer when doing a
   build.
-
-1.  Ensure you rebased your branch on the latest `dev` commit to avoid any merge conflicts.
-
-1.  Update the README.md with details of changes to the interface, this includes new environment 
+- Ensure you rebased your branch on the latest `dev` commit to avoid any merge conflicts.
+- Update the README.md with details of changes to the interface, this includes new environment
   variables, exposed ports, useful file locations and container parameters.
 
-1.  Increase the version numbers in any examples files and the README.md to the new version that this
+- Increase the version numbers in any examples files and the README.md to the new version that this
     Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/) :
 
     If the create is in developement stage, its format is 0.X.Y. In production stage, it's X.Y.Z.
@@ -103,5 +100,5 @@ Please note we have a specific workflow, please follow it in all your interactio
     Your crate should always start with 0.1.0 version and only pass in 1.0.0 when no big changes are
     planned. There is no need to rush a 1.0.0, take your time :)
 
-1.  You may merge the Merge Request in once you have the sign-off of two other developers. If you 
+- You may merge the Merge Request in once you have the sign-off of two other developers. If you
   do not have permission to do that, you may request the second reviewer to merge it for you.
\ No newline at end of file