Update docs to markdown style guide.

4 files changed, 39 insertions, 26 deletions

diff --git a/doc/workflow/README.md b/doc/workflow/README.md
index 39b3059e077..c715f6e5943 100644
--- a/doc/workflow/README.md
+++ b/doc/workflow/README.md
@@ -1,2 +1,3 @@
-+ [Workflow](workflow.md)
-+ [Project Features](project_features.md)
+- [Workflow](workflow.md)
+- [Project Features](project_features.md)
+- [Authorization for merge requests](authorization_for_merge_requests.md)
diff --git a/doc/workflow/authorization_for_merge_requests.md b/doc/workflow/authorization_for_merge_requests.md
index cc7031b11e1..d1d6d94ec11 100644
--- a/doc/workflow/authorization_for_merge_requests.md
+++ b/doc/workflow/authorization_for_merge_requests.md
@@ -5,9 +5,13 @@ There are two main ways to have a merge request flow with GitLab: working with p
 ## Protected branch flow
 
 With the protected branch flow everybody works within the same GitLab project.
+
 The project maintainers get Master access and the regular developers get Developer access.
+
 The maintainers mark the authoritative branches as 'Protected'.
+
 The developers push feature branches to the project and create merge requests to have their feature branches reviewed and merged into one of the protected branches.
+
 Only users with Master access can merge changes into a protected branch.
 
 ### Advantages
@@ -22,7 +26,9 @@ Only users with Master access can merge changes into a protected branch.
 ## Forking workflow
 
 With the forking workflow the maintainers get Master access and the regular developers get Reporter access to the authoritative repository, which prohibits them from pushing any changes to it.
+
 Developers create forks of the authoritative project and push their feature branches to their own forks.
+
 To get their changes into master they need to create a merge request across forks.
 
 ### Advantages
diff --git a/doc/workflow/project_features.md b/doc/workflow/project_features.md
index ec2c273db01..6ed9c1127a2 100644
--- a/doc/workflow/project_features.md
+++ b/doc/workflow/project_features.md
@@ -1,37 +1,41 @@
 # Project features
 
 When in a Project -> Settings, you will find Features on the bottom of the page that you can toggle.
-Below you will find a more elaborate explanation of each of these.
 
+Below you will find a more elaborate explanation of each of these.
 
 ## Issues
 
 Issues is a really powerful, but lightweight issue tracking system.
+
 You can make tickets, assign them to people, file them under milestones, order them with labels and have discussion in them.
-They integrate deeply into GitLab and are easily referenced from anywhere by using # and the issuenumber.
 
+They integrate deeply into GitLab and are easily referenced from anywhere by using `#` and the issue number.
 
 ## Merge Requests
 
 Using a merge request, you can review and discuss code before it is merged in the branch of your code.
+
 As with issues, it can be assigned; people, issues, etc. can be refereced; milestones attached.
-We see it as an integral part of working together on code and couldn't work without it.
 
+We see it as an integral part of working together on code and couldn't work without it.
 
 ## Wiki
 
 This is a separate system for documentation, built right into GitLab.
-It is source controlled and is very convenient if you don't want to keep you documentation in your source code, but you do want to keep it in your GitLab project.
 
+It is source controlled and is very convenient if you don't want to keep you documentation in your source code, but you do want to keep it in your GitLab project.
 
 ## Wall
 
 For simple, project specific conversations, the wall can be used.
-It's very lightweight and simple and works well if you're not interested in using issues, but still want to occasionally communicate within a project.
 
+It's very lightweight and simple and works well if you're not interested in using issues, but still want to occasionally communicate within a project.
 
 ## Snippets
 
 Snippets are little bits of code or text.
+
 This is a nice place to put code or text that is used semi-regularly within the project, but does not belong in source control.
+
 For example, a specific config file that is used by > the team that is only valid for the people that work on the code.
diff --git a/doc/workflow/workflow.md b/doc/workflow/workflow.md
index 8186cd53b20..ab29cfb670b 100644
--- a/doc/workflow/workflow.md
+++ b/doc/workflow/workflow.md
@@ -1,29 +1,31 @@
 # Workflow
 
-1. Clone project
+1.  Clone project:
 
-  ```bash
-  git clone git@example.com:project-name.git
-  ```
+    ```bash
+    git clone git@example.com:project-name.git
+    ```
 
-2. Create branch with your feature
+1.  Create branch with your feature:
 
-  ```bash
-  git checkout -b $feature_name
-  ```
+    ```bash
+    git checkout -b $feature_name
+    ```
 
-3. Write code. Commit changes
+1.  Write code. Commit changes:
 
-  ```bash
-  git commit -am "My feature is ready"
-  ```
+    ```bash
+    git commit -am "My feature is ready"
+    ```
 
-4. Push your branch to GitLab
+1.  Push your branch to GitLab:
 
-  ```bash
-  git push origin $feature_name
-  ```
+    ```bash
+    git push origin $feature_name
+    ```
 
-5. Review your code on commits page
-6. Create a merge request
-7. Your team lead will review the code & merge it to the main branch
+1.  Review your code on commits page.
+
+1.  Create a merge request.
+
+1.  Your team lead will review the code & merge it to the main branch.