Update docs to markdown style guide.

Author: cirosantilli

CONTRIBUTING.md

@@ -24,16 +24,11 @@ Issues and merge requests should be in English and contain appropriate language
 
 To get support for your particular problem please use the channels as detailed in the [getting help section of the readme](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/README.md#getting-help). Professional [support subscriptions](http://www.gitlab.com/subscription/) and [consulting services](http://www.gitlab.com/consultancy/) are available from [GitLab.com](http://www.gitlab.com/).
 
-The [issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues) is only for obvious errors in the latest [stable or development release of GitLab](MAINTENANCE.md).
-If something is wrong but it is not a regression compared to older versions of GitLab please do not open an issue but a feature request.
-When submitting an issue please conform to the issue submission guidelines listed below.
-Not all issues will be addressed and your issue is more likely to be addressed if you submit a merge request which partially or fully addresses the issue.
+The [issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues) is only for obvious errors in the latest [stable or development release of GitLab](MAINTENANCE.md). If something is wrong but it is not a regression compared to older versions of GitLab please do not open an issue but a feature request. When submitting an issue please conform to the issue submission guidelines listed below. Not all issues will be addressed and your issue is more likely to be addressed if you submit a merge request which partially or fully addresses the issue.
 
 Issues can be filed either at [gitlab.com](https://gitlab.com/gitlab-org/gitlab-ce/issues) or [github.com](https://github.com/gitlabhq/gitlabhq/issues).
 
-Do not use the issue tracker for feature requests.
-We have a specific [feature request forum](http://feedback.gitlab.com) for this purpose.
-Please keep feature requests as small and simple as possible, complex ones might be edited to make them small and simple.
+Do not use the issue tracker for feature requests. We have a specific [feature request forum](http://feedback.gitlab.com) for this purpose. Please keep feature requests as small and simple as possible, complex ones might be edited to make them small and simple.
 
 Please send a merge request with a tested solution or a merge request with a failing test instead of opening an issue if you can. If you're unsure where to post, post to the [mailing list](https://groups.google.com/forum/#!forum/gitlabhq) or [Stack Overflow](http://stackoverflow.com/questions/tagged/gitlab) first. There are a lot of helpful GitLab users there who may be able to help you quickly. If your particular issue turns out to be a bug, it will find its way from there.
 
@@ -42,16 +37,16 @@ Please send a merge request with a tested solution or a merge request with a fai
 **[Search the issues](https://gitlab.com/gitlab-org/gitlab-ce/issues)** for similar entries before submitting your own, there's a good chance somebody else had the same issue. Show your support with `:+1:` and/or join the discussion. Please submit issues in the following format (as the first post):
 
 1. **Summary:** Summarize your issue in one sentence (what goes wrong, what did you expect to happen)
-2. **Steps to reproduce:** How can we reproduce the issue, preferably on the [GitLab development virtual machine with vagrant](https://gitlab.com/gitlab-org/cookbook-gitlab/blob/master/doc/development.md) (start your issue with: `vagrant destroy && vagrant up && vagrant ssh`)
-3. **Expected behavior:** Describe your issue in detail
-4. **Observed behavior**
-5. **Relevant logs and/or screenshots:** Please use code blocks (\`\`\`) to format console output, logs, and code as it's very hard to read otherwise.
-6. **Output of checks**
+1. **Steps to reproduce:** How can we reproduce the issue, preferably on the [GitLab development virtual machine with vagrant](https://gitlab.com/gitlab-org/cookbook-gitlab/blob/master/doc/development.md) (start your issue with: `vagrant destroy && vagrant up && vagrant ssh`)
+1. **Expected behavior:** Describe your issue in detail
+1. **Observed behavior**
+1. **Relevant logs and/or screenshots:** Please use code blocks (\`\`\`) to format console output, logs, and code as it's very hard to read otherwise.
+1. **Output of checks**
     * Results of GitLab [Application Check](doc/install/installation.md#check-application-status) (`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production`); we will only investigate if the tests are passing
     * Version of GitLab you are running; we will only investigate issues in the latest stable and development releases as per the [maintenance policy](MAINTENANCE.md)
     * Add the last commit sha1 of the GitLab version you used to replicate the issue (obtainable from the help page)
     * Describe your setup (use relevant parts from `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
-7. **Possible fixes**: If you can, link to the line of code that might be responsible for the problem
+1. **Possible fixes**: If you can, link to the line of code that might be responsible for the problem
 
 ## Merge requests
 
@@ -87,10 +82,10 @@ For examples of feedback on merge requests please look at already [closed merge
 **Please format your merge request description as follows:**
 
 1. What does this MR do?
-2. Are there points in the code the reviewer needs to double check?
-3. Why was this MR needed?
-4. What are the relevant issue numbers / [Feature requests](http://feedback.gitlab.com/)?
-5. Screenshots (If appropiate)
+1. Are there points in the code the reviewer needs to double check?
+1. Why was this MR needed?
+1. What are the relevant issue numbers / [Feature requests](http://feedback.gitlab.com/)?
+1. Screenshots (If appropiate)
 
 ## Contribution acceptance criteria
 
@@ -106,6 +101,7 @@ For examples of feedback on merge requests please look at already [closed merge
 1. It conforms to the following style guides
 
 ## Style guides
+
 1. [Ruby](https://github.com/bbatsov/ruby-style-guide)
 1. [Rails](https://github.com/bbatsov/rails-style-guide)
 1. [Formatting](https://github.com/thoughtbot/guides/tree/master/style#formatting)

MAINTENANCE.md

@@ -1,24 +1,14 @@
 # GitLab Maintenance Policy
 
-GitLab is a fast moving and evolving project. We currently don't have the
-resources to support many releases concurrently. We support exactly one stable
-release at any given time.
+GitLab is a fast moving and evolving project. We currently don't have the resources to support many releases concurrently. We support exactly one stable release at any given time.
 
-GitLab follows the [Semantic Versioning](http://semver.org/) for its releases:
-`(Major).(Minor).(Patch)`.
+GitLab follows the [Semantic Versioning](http://semver.org/) for its releases: `(Major).(Minor).(Patch)`.
 
-* **Major version**: Whenever there is something significant or any backwards
-  incompatible changes are introduced to the public API.
-* **Minor version**: When new, backwards compatible functionality is introduced
-  to the public API or a minor feature is introduced, or when a set of smaller
-  features is rolled out.
-* **Patch number**: When backwards compatible bug fixes are introduced that fix
-  incorrect behavior.
+- **Major version**: Whenever there is something significant or any backwards incompatible changes are introduced to the public API.
+- **Minor version**: When new, backwards compatible functionality is introduced to the public API or a minor feature is introduced, or when a set of smaller features is rolled out.
+- **Patch number**: When backwards compatible bug fixes are introduced that fix incorrect behavior.
 
-The current stable release will receive security patches and bug fixes
-(eg. `5.0` -> `5.0.1`).  Feature releases will mark the next supported stable
-release where the minor version is increased numerically by increments of one
-(eg. `5.0 -> 5.1`).
+The current stable release will receive security patches and bug fixes (eg. `5.0` -> `5.0.1`).  Feature releases will mark the next supported stable release where the minor version is increased numerically by increments of one (eg. `5.0 -> 5.1`).
 
 We encourage everyone to run the latest stable release to ensure that you can easily upgrade to the most secure and feature rich GitLab experience. In order to make sure you can easily run the most recent stable release, we are working hard to keep the update process simple and reliable.
 

PROCESS.md

@@ -24,9 +24,9 @@ Below we describe the contributing process to GitLab for two reasons. So that co
 ## Priorities of the issue team
 
 1. Mentioning people (critical)
-2. Workflow labels (normal)
-3. Functional labels (minor)
-4. Assigning issues (avoid if possible)
+1. Workflow labels (normal)
+1. Functional labels (minor)
+1. Assigning issues (avoid if possible)
 
 ## Mentioning people
 
@@ -36,11 +36,11 @@ The most important thing is making sure valid issues receive feedback from the d
 
 Workflow labels are purposely not very detailed since that would be hard to keep updated as you would need to reevaluate them after every comment. We optionally use functional labels on demand when want to group related issues to get an overview (for example all issues related to RVM, to tackle them in one go) and to add details to the issue. 
 
-- _Awaiting feedback_: Feedback pending from the reporter
-- _Awaiting confirmation of fix_: The issue should already be solved in **master** (generally you can avoid this workflow item and just close the issue right away)
-- _Attached MR_: There is a MR attached and the discussion should happen there
-  - We need to let issues stay in sync with the MR's. We can do this with a "Closing #XXXX" or "Fixes #XXXX" comment in the MR. We can't close the issue when there is a merge request because sometimes a MR is not good and we just close the MR, then the issue must stay.
-- _Awaiting developer action/feedback_: Issue needs to be fixed or clarified by a developer
+-   *Awaiting feedback*: Feedback pending from the reporter
+-   *Awaiting confirmation of fix*: The issue should already be solved in **master** (generally you can avoid this workflow item and just close the issue right away)
+-   *Attached MR*: There is a MR attached and the discussion should happen there
+    - We need to let issues stay in sync with the MR's. We can do this with a "Closing #XXXX" or "Fixes #XXXX" comment in the MR. We can't close the issue when there is a merge request because sometimes a MR is not good and we just close the MR, then the issue must stay.
+-   *Awaiting developer action/feedback*: Issue needs to be fixed or clarified by a developer
 
 ## Functional labels
 
@@ -51,12 +51,13 @@ These labels describe what development specialities are involved such as: Postgr
 If an issue is complex and needs the attention of a specific person, assignment is a good option but assigning issues might discourage other people from contributing to that issue. We need all the contributions we can get so this should never be discouraged. Also, an assigned person might not have time for a few weeks, so others should feel free to takeover.
 
 ## Label colors
-- Light orange `#fef2c0`: workflow labels for issue team members (awaiting feedback, awaiting confirmation of fix)
-- Bright orange `#eb6420`: workflow labels for core team members (attached MR, awaiting developer action/feedback)
-- Light blue `#82C5FF`: functional labels
-- Green labels `#009800`: issues that can generally be ignored. For example, issues given the following labels normally can be closed immediately:
-  - Feature request (see copy & paste response: [Feature requests](#feature-requests))
-  - Support (see copy & paste response: [Support requests and configuration questions](#support-requests-and-configuration-questions)
+
+-   Light orange `#fef2c0`: workflow labels for issue team members (awaiting feedback, awaiting confirmation of fix)
+-   Bright orange `#eb6420`: workflow labels for core team members (attached MR, awaiting developer action/feedback)
+-   Light blue `#82C5FF`: functional labels
+-   Green labels `#009800`: issues that can generally be ignored. For example, issues given the following labels normally can be closed immediately:
+    - Feature request (see copy & paste response: [Feature requests](#feature-requests))
+    - Support (see copy & paste response: [Support requests and configuration questions](#support-requests-and-configuration-questions)
 
 ## Be kind
 
@@ -102,8 +103,4 @@ This merge request has been closed because a request for more information has no
 
 ### Accepting merge requests
 
-Is there a request on [the feature request forum](http://feedback.gitlab.com/forums/176466-general) that is similar to this?
-If so, can you make a comment with a link to it?
-Please be aware that new functionality that is not marked [accepting merge/pull requests](http://feedback.gitlab.com/forums/176466-general/status/796455) on the forum might not make it into GitLab.
-You might be asked to make changes and even after implementing them your feature might still be declined.
-If you want to reduce the chance of this happening please have a discussion in the forum first.
+Is there a request on [the feature request forum](http://feedback.gitlab.com/forums/176466-general) that is similar to this? If so, can you make a comment with a link to it? Please be aware that new functionality that is not marked [accepting merge/pull requests](http://feedback.gitlab.com/forums/176466-general/status/796455) on the forum might not make it into GitLab. You might be asked to make changes and even after implementing them your feature might still be declined. If you want to reduce the chance of this happening please have a discussion in the forum first.