diff --git a/doc/api/issues.md b/doc/api/issues.md
index ceeb683a6bfab231c5ba242202560a69ef402827..8d073c46d331bf07fcb14f349482c754741c2458 100644
--- a/doc/api/issues.md
+++ b/doc/api/issues.md
@@ -56,7 +56,7 @@ Parameters:
       "title": "v1.0",
       "description": "",
       "due_date": "2012-07-20",
-      "state": "reopenend",
+      "state": "reopened",
       "updated_at": "2012-07-04T13:42:48Z",
       "created_at": "2012-07-04T13:42:48Z"
     },
diff --git a/doc/api/oauth2.md b/doc/api/oauth2.md
index b2dbba9bdeb2716dbffcb1a1d0e3e6d9b1937875..7bb391054ce0f588cbd620e861be13ed9a43e594 100644
--- a/doc/api/oauth2.md
+++ b/doc/api/oauth2.md
@@ -4,7 +4,7 @@ OAuth2 is a protocol that enables us to get access to private details of user's
 
 Before using the OAuth2 you should create an application in user's account. Each application getting unique App ID and App Secret parameters. You should not share them.
 
-This functianolity is based on [doorkeeper gem](https://github.com/doorkeeper-gem/doorkeeper)
+This functionality is based on [doorkeeper gem](https://github.com/doorkeeper-gem/doorkeeper)
 
 ## Web Application Flow
 
@@ -15,7 +15,7 @@ This flow consists from 3 steps.
 
 ### 1. Registering the client
 
-Creat an application in user's account profile.
+Create an application in user's account profile.
 
 ### 2. Requesting authorization
 
@@ -96,4 +96,4 @@ For testing you can use the oauth2 ruby gem:
 client = OAuth2::Client.new('the_client_id', 'the_client_secret', :site => "http://example.com")
 access_token = client.password.get_token('user@example.com', 'sekret')
 puts access_token.token
-```
\ No newline at end of file
+```
diff --git a/doc/api/projects.md b/doc/api/projects.md
index d7804689c25e980e7c3724c3c0f53aff0db772f8..559d35d316a200021cdaf31abf872a7cc16d89c8 100644
--- a/doc/api/projects.md
+++ b/doc/api/projects.md
@@ -541,7 +541,7 @@ Parameters:
         }
       ],
       "tree": "c68537c6534a02cc2b176ca1549f4ffa190b58ee",
-      "message": "give caolan credit where it's due (up top)",
+      "message": "give Caolan credit where it's due (up top)",
       "author": {
         "name": "Jeremy Ashkenas",
         "email": "jashkenas@example.com"
diff --git a/doc/api/services.md b/doc/api/services.md
index 93534d5502e80b8f0d39c92cea74152e0b94454d..cbf767d1b251a773520f158229bdb1e21e0c7e22 100644
--- a/doc/api/services.md
+++ b/doc/api/services.md
@@ -23,23 +23,23 @@ Delete GitLab CI service settings for a project.
 DELETE /projects/:id/services/gitlab-ci
 ```
 
-## Hipchat
+## HipChat
 
-### Edit Hipchat service
+### Edit HipChat service
 
-Set Hipchat service for project.
+Set HipChat service for project.
 
 ```
 PUT /projects/:id/services/hipchat
 ```
 Parameters:
 
-- `token` (required) - Hipchat token
-- `room` (required) - Hipchat room name
+- `token` (required) - HipChat token
+- `room` (required) - HipChat room name
 
-### Delete Hipchat service
+### Delete HipChat service
 
-Delete Hipchat service for a project.
+Delete HipChat service for a project.
 
 ```
 DELETE /projects/:id/services/hipchat
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 209182e7742d54b7deb708fea8906ec044ed5b8d..714cc01600416fba76dadd5054b872ec5f90ec7e 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -16,8 +16,8 @@ You can imagine GitLab as a physical office.
 They can be stored in a warehouse.
 This can be either a hard disk, or something more complex, such as a NFS filesystem;
 
-**NginX** acts like the front-desk.
-Users come to NginX and request actions to be done by workers in the office;
+**Nginx** acts like the front-desk.
+Users come to Nginx and request actions to be done by workers in the office;
 
 **The database** is a series of metal file cabinets with information on:
  - The goods in the warehouse (metadata, issues, merge requests etc);
@@ -70,7 +70,7 @@ To summarize here's the [directory structure of the `git` user home directory](.
 
     ps aux | grep '^git'
 
-GitLab has several components to operate. As a system user (i.e. any user that is not the `git` user) it requires a persistent database (MySQL/PostreSQL) and redis database. It also uses Apache httpd or nginx to proxypass Unicorn. As the `git` user it starts Sidekiq and Unicorn (a simple ruby HTTP server running on port `8080` by default). Under the GitLab user there are normally 4 processes: `unicorn_rails master` (1 process), `unicorn_rails worker` (2 processes), `sidekiq` (1 process).
+GitLab has several components to operate. As a system user (i.e. any user that is not the `git` user) it requires a persistent database (MySQL/PostreSQL) and redis database. It also uses Apache httpd or Nginx to proxypass Unicorn. As the `git` user it starts Sidekiq and Unicorn (a simple ruby HTTP server running on port `8080` by default). Under the GitLab user there are normally 4 processes: `unicorn_rails master` (1 process), `unicorn_rails worker` (2 processes), `sidekiq` (1 process).
 
 ### Repository access
 
@@ -146,13 +146,13 @@ nginx
 
 Apache httpd
 
-- [Explanation of apache logs](http://httpd.apache.org/docs/2.2/logs.html).
+- [Explanation of Apache logs](http://httpd.apache.org/docs/2.2/logs.html).
 - `/var/log/apache2/` contains error and output logs (on Ubuntu).
 - `/var/log/httpd/` contains error and output logs (on RHEL).
 
 redis
 
-- `/var/log/redis/redis.log` there are also logrotated logs there.
+- `/var/log/redis/redis.log` there are also log-rotated logs there.
 
 PostgreSQL
 
diff --git a/doc/development/ci_setup.md b/doc/development/ci_setup.md
index ee16aedafe7563459502fa895ff1cda5f3089120..f417667754eda6e9fa64277b7973bf8d425ed051 100644
--- a/doc/development/ci_setup.md
+++ b/doc/development/ci_setup.md
@@ -26,7 +26,7 @@ We use [these build scripts](https://gitlab.com/gitlab-org/gitlab-ci/blob/master
 # Build configuration on [Semaphore](https://semaphoreapp.com/gitlabhq/gitlabhq/) for testing the [GitHub.com repo](https://github.com/gitlabhq/gitlabhq)
 
 - Language: Ruby
-- Ruby verion: 2.1.2
+- Ruby version: 2.1.2
 - database.yml: pg
 
 Build commands
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index 8eabb219b1b22f12afc2afa4203053ae0f5e6697..2cf9e82fd214ba8bf818defd86d371acbd630cdf 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -7,7 +7,7 @@
 - Ubuntu
 - Debian
 - CentOS
-- RedHat Enterprise Linux (please use the CentOS packages and instructions)
+- Red Hat Enterprise Linux (please use the CentOS packages and instructions)
 - Scientific Linux (please use the CentOS packages and instructions)
 - Oracle Linux (please use the CentOS packages and instructions)
 
diff --git a/doc/integration/README.md b/doc/integration/README.md
index 357ed0383146ac1b9a03b713788bce2906c0b37d..0087167bb842f3d9bf4d8d205aad365a37e2d2f6 100644
--- a/doc/integration/README.md
+++ b/doc/integration/README.md
@@ -13,7 +13,7 @@ Jenkins support is [available in GitLab EE](http://doc.gitlab.com/ee/integration
 
 ## Project services
 
-Integration with services such as Campfire, Flowdock, Gemnasium, HipChat, PivotalTracker and Slack are available in the from of a Project Service.
+Integration with services such as Campfire, Flowdock, Gemnasium, HipChat, Pivotal Tracker, and Slack are available in the form of a Project Service.
 You can find these within GitLab in the Services page under Project Settings if you are at least a master on the project.
 Project Services are a bit like plugins in that they allow a lot of freedom in adding functionality to GitLab, for example there is also a service that can send an email every time someone pushes new commits.
 Because GitLab is open source we can ship with the code and tests for all plugins.
diff --git a/doc/integration/external-issue-tracker.md b/doc/integration/external-issue-tracker.md
index 87af94512ed3ee09ac17612e59460e5bf90af91b..ba4df9f8fe02bc847520268064963d1355a3ec1e 100644
--- a/doc/integration/external-issue-tracker.md
+++ b/doc/integration/external-issue-tracker.md
@@ -6,7 +6,7 @@ GitLab has a great issue tracker but you can also use an external issue tracker
 - clicking 'New issue' on the project dashboard creates a new JIRA issue;
 - To reference JIRA issue PROJECT-1234 in comments, use syntax PROJECT-1234. Commit messages get turned into HTML links to the corresponding JIRA issue.
 
-![jira screenshot](jira-integration-points.png)
+![Jira screenshot](jira-integration-points.png)
 
 You can configure the integration in the gitlab.yml configuration file.
 
diff --git a/doc/integration/gitlab_buttons_in_gmail.md b/doc/integration/gitlab_buttons_in_gmail.md
index 0816509c557e5da8dd69f1052bf26ea815fd7913..a9885cef1092ce710ffb7981dd7c810b11329903 100644
--- a/doc/integration/gitlab_buttons_in_gmail.md
+++ b/doc/integration/gitlab_buttons_in_gmail.md
@@ -1,4 +1,4 @@
-# GitLab buttons in gmail
+# GitLab buttons in Gmail
 
 GitLab supports [Google actions in email](https://developers.google.com/gmail/markup/actions/actions-overview).
 
@@ -25,4 +25,4 @@ If you receive "No errors detected" message from the tester you can send the ema
 
 ```bash
 bundle exec rake gitlab:mail_google_schema_whitelisting RAILS_ENV=production SEND=true
-``
+```
diff --git a/doc/integration/shibboleth.md b/doc/integration/shibboleth.md
index 1b03197b6c7d454b61c441cb2957e828b64aa677..ea11f1afeab8db0346a292c76ba323565ececd02 100644
--- a/doc/integration/shibboleth.md
+++ b/doc/integration/shibboleth.md
@@ -2,7 +2,7 @@
 
 This documentation is for enabling shibboleth with gitlab-omnibus package.
 
-In order to enable Shibboleth support in gitlab we need to use Apache instead of Nginx (It may be possible to use Nginx, however I did not found way to easily configure nginx that is bundled in gitlab-omnibus package). Apache uses mod_shib2 module for shibboleth authentication and can pass attributes as headers to omniauth-shibboleth provider. 
+In order to enable Shibboleth support in gitlab we need to use Apache instead of Nginx (It may be possible to use Nginx, however I did not found way to easily configure Nginx that is bundled in gitlab-omnibus package). Apache uses mod_shib2 module for shibboleth authentication and can pass attributes as headers to omniauth-shibboleth provider. 
 
 
 To enable the Shibboleth OmniAuth provider you must:
@@ -10,7 +10,7 @@ To enable the Shibboleth OmniAuth provider you must:
 1. Configure Apache shibboleth module. Installation and configuration of module it self is out of scope of this document. 
 Check https://wiki.shibboleth.net/ for more info.
 
-1. You can find Apache config in gitlab-reciepes (https://github.com/gitlabhq/gitlab-recipes/blob/master/web-server/apache/gitlab-ssl.conf)
+1. You can find Apache config in gitlab-recipes (https://github.com/gitlabhq/gitlab-recipes/blob/master/web-server/apache/gitlab-ssl.conf)
 
 Following changes are needed to enable shibboleth:
 
@@ -34,7 +34,7 @@ protect omniauth-shibboleth callback URL:
 ```
 exclude shibboleth URLs from rewriting, add "RewriteCond %{REQUEST_URI} !/Shibboleth.sso" and "RewriteCond %{REQUEST_URI} !/shibboleth-sp", config should look like this:
 ```
-  #apache equivalent of nginx try files
+  # Apache equivalent of Nginx try files
   RewriteEngine on
   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_URI} !/Shibboleth.sso 
@@ -50,7 +50,7 @@ File it should look like this:
 external_url 'https://gitlab.example.com'
 gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
 
-# disable nginx
+# disable Nginx
 nginx['enable'] = false
 
 gitlab_rails['omniauth_allow_single_sign_on'] = true
diff --git a/doc/markdown/markdown.md b/doc/markdown/markdown.md
index 7b79cd5d98bff37edfeb4af416bda7dd1f4f0b5c..2568245e9c2f5783b996bcb7df278de7de14801b 100644
--- a/doc/markdown/markdown.md
+++ b/doc/markdown/markdown.md
@@ -6,7 +6,7 @@
 
 * [Newlines](#newlines)
 * [Multiple underscores in words](#multiple-underscores-in-words)
-* [URL autolinking](#url-autolinking)
+* [URL auto-linking](#url-autolinking)
 * [Code and Syntax Highlighting](#code-and-syntax-highlighting)
 * [Emoji](#emoji)
 * [Special GitLab references](#special-gitlab-references)
@@ -40,7 +40,7 @@ You can use GFM in
 - milestones
 - wiki pages
 
-You can also use other rich text files in GitLab. You might have to install a depency to do so. Please see the [github-markup gem readme](https://github.com/gitlabhq/markup#markups) for more information.
+You can also use other rich text files in GitLab. You might have to install a dependency to do so. Please see the [github-markup gem readme](https://github.com/gitlabhq/markup#markups) for more information.
 
 ## Newlines
 
@@ -68,7 +68,7 @@ It is not reasonable to italicize just _part_ of a word, especially when you're
 perform_complicated_task
 do_this_and_do_that_and_another_thing
 
-## URL autolinking
+## URL auto-linking
 
 GFM will autolink standard URLs you copy and paste into your text. So if you want to link to a URL (instead of a textural link), you can simply put the URL in verbatim and it will be turned into a link to that URL.
 
diff --git a/doc/project_services/project_services.md b/doc/project_services/project_services.md
index ec46af5fe3be19eaf3bc1fb3f7ae6017c3cd4b0e..93a57485cfd3a8e346ae0c33f7448b52d062c16c 100644
--- a/doc/project_services/project_services.md
+++ b/doc/project_services/project_services.md
@@ -4,16 +4,16 @@ __Project integrations with external services for continuous integration and mor
 
 ## Services
 
-- Assemblia
-- [Atlassian Bamboo CI](bamboo.md) An Atlassian product for continous integration.
+- Assembla
+- [Atlassian Bamboo CI](bamboo.md) An Atlassian product for continuous integration.
 - Build box
 - Campfire
 - Emails on push
 - Flowdock
 - Gemnasium
 - GitLab CI
-- Hipchat
-- PivotalTracker
+- HipChat
+- Pivotal Tracker
 - Pushover
 - Slack
-- TeamCity
\ No newline at end of file
+- TeamCity
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 50cd0d08b5a5843a6466a3c4d2a3ec1d2084c6a3..bbcf395c7453c5e6ec917a45623cf69b289210d0 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -214,19 +214,19 @@ This is recommended to reduce cron spam.
 If your GitLab server contains a lot of Git repository data you may find the GitLab backup script to be too slow.
 In this case you can consider using filesystem snapshots as part of your backup strategy.
 
-Example: Amazone EBS
+Example: Amazon EBS
 
 > A GitLab server using omnibus-gitlab hosted on Amazon AWS.
 > An EBS drive containing an ext4 filesystem is mounted at `/var/opt/gitlab`.
 > In this case you could make an application backup by taking an EBS snapshot.
 > The backup includes all repositories, uploads and Postgres data.
 
-Example: LVM snapshots + Rsync
+Example: LVM snapshots + rsync
 
 > A GitLab server using omnibus-gitlab, with an LVM logical volume mounted at `/var/opt/gitlab`.
-> Replicating the `/var/opt/gitlab` directory usign Rsync would not be reliable because too many files would change while Rsync is running.
+> Replicating the `/var/opt/gitlab` directory using rsync would not be reliable because too many files would change while rsync is running.
 > Instead of rsync-ing `/var/opt/gitlab`, we create a temporary LVM snapshot, which we mount as a read-only filesystem at `/mnt/gitlab_backup`.
-> Now we can have a longer running Rsync job which will create a consistent replica on the remote server.
+> Now we can have a longer running rsync job which will create a consistent replica on the remote server.
 > The replica includes all repositories, uploads and Postgres data.
 
 If you are running GitLab on a virtualized server you can possibly also create VM snapshots of the entire GitLab server.
diff --git a/doc/release/howto_rc1.md b/doc/release/howto_rc1.md
index 25923d16f3486e42bd75258aa2ad2cdaacb0d569..e8e8c8a821de1f9125490459138e87395045c736 100644
--- a/doc/release/howto_rc1.md
+++ b/doc/release/howto_rc1.md
@@ -104,7 +104,7 @@ bundle exec rake release["x.x.0.rc1"]
 ```
 
 Now developers can use master for merging new features.
-So you should use stable branch for future code chages related to release.
+So you should use stable branch for future code changes related to release.
 
 
 ### 5. Release GitLab CI RC1
diff --git a/doc/release/monthly.md b/doc/release/monthly.md
index 175112b90c6d79a8e7b4d9a6884043d31ed97c9c..4297bc7e2b7a4ffaa04349c101f1ec47403f9059 100644
--- a/doc/release/monthly.md
+++ b/doc/release/monthly.md
@@ -207,7 +207,7 @@ __3. Tweet to blog__
 Send out a tweet to share the good news with the world.
 List the most important features and link to the blog post.
 
-Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE <link-to-blogpost> #gitlab"
+Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE &lt;link-to-blog-post&gt; #gitlab"
 
 Consider creating a post on Hacker News.
 
diff --git a/doc/security/information_exclusivity.md b/doc/security/information_exclusivity.md
index 127166ae2e7fac4f9fb16425998465ebc3efc33b..f8e7fc3fd0ec5f3b36a5c2791be7ebefe946f1e0 100644
--- a/doc/security/information_exclusivity.md
+++ b/doc/security/information_exclusivity.md
@@ -4,6 +4,6 @@ Git is a distributed version control system (DVCS).
 This means that everyone that works with the source code has a local copy of the complete repository.
 In GitLab every project member that is not a guest (so reporters, developers and masters) can clone the repository to get a local copy.
 After obtaining this local copy the user can upload the full repository anywhere, including another project under their control or another server.
-The consequense is that you can't build access controls that prevent the intentional sharing of source code by users that have access to the source code.
+The consequence is that you can't build access controls that prevent the intentional sharing of source code by users that have access to the source code.
 This is an inherent feature of a DVCS and all git management systems have this limitation.
 Obviously you can take steps to prevent unintentional sharing and information destruction, this is why only some people are allowed to invite others and nobody can force push a protected branch.
diff --git a/doc/ssh/README.md b/doc/ssh/README.md
index c87fffd7d2ca1494354329097493bef13703f6fb..6fe23dfa2a6105699738e70898a1169fd887e54e 100644
--- a/doc/ssh/README.md
+++ b/doc/ssh/README.md
@@ -1,4 +1,73 @@
 # SSH
 
-- [Deploy keys](deploy_keys.md)
-- [SSH](ssh.md)
+## SSH keys
+
+An SSH key allows you to establish a secure connection between your
+computer and GitLab.
+
+Before generating an SSH key, check if your system already has one by
+running `cat ~/.ssh/id_rsa.pub`. If you see a long string starting with
+`ssh-rsa` or `ssh-dsa`, you can skip the ssh-keygen step.
+
+To generate a new SSH key, just open your terminal and use code below. The
+ssh-keygen command prompts you for a location and filename to store the key
+pair and for a password. When prompted for the location and filename, you
+can press enter to use the default.
+
+It is a best practice to use a password for an SSH key, but it is not
+required and you can skip creating a password by pressing enter. Note that
+the password you choose here can't be altered or retrieved.
+
+```bash
+ssh-keygen -t rsa -C "$your_email"
+```
+
+Use the code below to show your public key.
+
+```bash
+cat ~/.ssh/id_rsa.pub
+```
+
+Copy-paste the key to the 'My SSH Keys' section under the 'SSH' tab in your
+user profile. Please copy the complete key starting with `ssh-` and ending
+with your username and host.  
+
+Use code below to copy your public key to the clipboard. Depending on your
+OS you'll need to use a different command:
+
+**Windows:**
+```bash
+clip < ~/.ssh/id_rsa.pub
+```
+
+**Mac:**
+```bash
+pbcopy < ~/.ssh/id_rsa.pub
+```
+
+**Linux (requires xclip):**
+```bash
+xclip -sel clip < ~/.ssh/id_rsa.pub
+```
+
+## Deploy keys
+
+Deploy keys allow read-only access to multiple projects with a single SSH
+key.
+
+This is really useful for cloning repositories to your Continuous
+Integration (CI) server. By using deploy keys, you don't have to setup a
+dummy user account.
+
+If you are a project master or owner, you can add a deploy key in the
+project settings under the section 'Deploy Keys'. Press the 'New Deploy
+Key' button and upload a public SSH key. After this, the machine that uses
+the corresponding private key has read-only access to the project.
+
+You can't add the same deploy key twice with the 'New Deploy Key' option.
+If you want to add the same key to another project, please enable it in the
+list that says 'Deploy keys from projects available to you'. All the deploy
+keys of all the projects you have access to are available. This project
+access can happen through being a direct member of the projecti, or through
+a group. See `def accessible_deploy_keys` in `app/models/user.rb` for more
+information.
diff --git a/doc/ssh/deploy_keys.md b/doc/ssh/deploy_keys.md
deleted file mode 100644
index dcca8bdc61aa4f9d327d8943d2353f901384942a..0000000000000000000000000000000000000000
--- a/doc/ssh/deploy_keys.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Deploy keys
-
-Deploy keys allow read-only access one or multiple projects with a single SSH key.
-
-This is really useful for cloning repositories to your Continuous Integration (CI) server. By using a deploy keys you don't have to setup a dummy user account.
-
-If you are a project master or owner you can add a deploy key in the project settings under the section Deploy Keys. Press the 'New Deploy Key' button and upload a public ssh key. After this the machine that uses the corresponding private key has read-only access to the project.
-
-You can't add the same deploy key twice with the 'New Deploy Key' option. If you want to add the same key to another project please enable it in the list that says 'Deploy keys from projects available to you'. All the deploy keys of all the projects you have access to are available. This project access can happen through being a direct member of the project or through a group. See `def accessible_deploy_keys` in `app/models/user.rb` for more information.
diff --git a/doc/ssh/ssh.md b/doc/ssh/ssh.md
deleted file mode 100644
index f9ee627f1f5cb604e52559a9ad6f2242ffcb5653..0000000000000000000000000000000000000000
--- a/doc/ssh/ssh.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# SSH keys
-
-SSH key allows you to establish a secure connection between your computer and GitLab
-
-Before generating an SSH key, check if your system already has one by running `cat ~/.ssh/id_rsa.pub` If your see a long string starting with `ssh-rsa` or `ssh-dsa`, you can skip the ssh-keygen step.
-
-To generate a new SSH key just open your terminal and use code below. The ssh-keygen command prompts you for a location and filename to store the key pair and for a password. When prompted for the location and filename you can press enter to use the default. 
-It is a best practice to use a password for an SSH key but it is not required and you can skip creating a password by pressing enter. 
-Note that the password you choose here can't be altered or retrieved.
-
-```bash
-ssh-keygen -t rsa -C "$your_email"
-```
-
-Use the code below to show your public key.
-
-```bash
-cat ~/.ssh/id_rsa.pub
-```
-
-Copy-paste the key to the 'My SSH Keys' section under the 'SSH' tab in your user profile. Please copy the complete key starting with `ssh-` and ending with your username and host.  
-
-Use code below to copy your public key to the clipboard. Depending on your OS you'll need to use a different command:
-
-**Windows:**
-```bash
-clip < ~/.ssh/id_rsa.pub
-```
-
-**Mac:**
-```bash
-pbcopy < ~/.ssh/id_rsa.pub
-```
-
-**Linux (requires xclip):**
-```bash
-xclip -sel clip < ~/.ssh/id_rsa.pub
-```
diff --git a/doc/system_hooks/system_hooks.md b/doc/system_hooks/system_hooks.md
index 41c2732ef77f1ecffa82a43ba4e3bde063defa52..f9b6d37d8405fdab0411353642b905331179396c 100644
--- a/doc/system_hooks/system_hooks.md
+++ b/doc/system_hooks/system_hooks.md
@@ -15,8 +15,8 @@ System hooks can be used, e.g. for logging or changing information in a LDAP ser
                 "name": "StoreCloud",
          "owner_email": "johnsmith@gmail.com",
           "owner_name": "John Smith",
-                "path": "stormcloud",
- "path_with_namespace": "jsmith/stormcloud",
+                "path": "storecloud",
+ "path_with_namespace": "jsmith/storecloud",
           "project_id": 74,
   "project_visibility": "private",
 }
@@ -126,10 +126,10 @@ System hooks can be used, e.g. for logging or changing information in a LDAP ser
 {
    "created_at": "2012-07-21T07:30:54Z",
    "event_name": "group_create",
-         "name": "StormCloud",
+         "name": "StoreCloud",
   "owner_email": "johnsmith@gmail.com",
    "owner_name": "John Smith",
-         "path": "stormcloud",
+         "path": "storecloud",
      "group_id": 78
 }
 ```
diff --git a/doc/update/2.6-to-3.0.md b/doc/update/2.6-to-3.0.md
index 6aabbe095dc0c1c45f64546876fa8a3f4623198a..2044b659468056ebf9a6fb71e60eafed0a50cbd8 100644
--- a/doc/update/2.6-to-3.0.md
+++ b/doc/update/2.6-to-3.0.md
@@ -22,29 +22,29 @@ sudo -u gitlab bundle exec rake db:migrate RAILS_ENV=production
 # !!! Config should be replaced with a new one. Check it after replace
 cp config/gitlab.yml.example config/gitlab.yml
 
-# update gitolite hooks
+# update Gitolite hooks
 
-# GITOLITE v2:
+# Gitolite v2:
 sudo cp ./lib/hooks/post-receive /home/git/share/gitolite/hooks/common/post-receive
 sudo chown git:git /home/git/share/gitolite/hooks/common/post-receive
 
-# GITOLITE v3:
+# Gitolite v3:
 sudo cp ./lib/hooks/post-receive /home/git/.gitolite/hooks/common/post-receive
 sudo chown git:git /home/git/.gitolite/hooks/common/post-receive
 
 # set valid path to hooks in gitlab.yml in git_host section
 # like this
 git_host:
-  # gitolite 2
+  # Gitolite 2
   hooks_path: /home/git/share/gitolite/hooks
-  # gitolite 3
+  # Gitolite 3
   hooks_path: /home/git/.gitolite/hooks/
 
 
-# Make some changes to gitolite config
+# Make some changes to Gitolite config
 # For more information visit https://github.com/gitlabhq/gitlabhq/pull/1719
 
-# gitolite v2
+# Gitolite v2
 sudo -u git -H sed -i 's/\(GL_GITCONFIG_KEYS\s*=>*\s*\).\{2\}/\\1"\.\*"/g' /home/git/.gitolite.rc
 
 # gitlite v3
diff --git a/doc/update/4.2-to-5.0.md b/doc/update/4.2-to-5.0.md
index 7974ae47ff4e96515ffe2784fddd6759685374be..0a929591dec98298c93d83c1c7a61bc210e0489f 100644
--- a/doc/update/4.2-to-5.0.md
+++ b/doc/update/4.2-to-5.0.md
@@ -111,7 +111,7 @@ sudo chmod -R u+rwX  /home/git/gitlab/tmp/pids
 
 ```
 
-## 6. Update init.d script and nginx config
+## 6. Update init.d script and Nginx config
 
 ```bash
 # init.d
@@ -123,7 +123,7 @@ sudo chmod +x /etc/init.d/gitlab
 sudo -u git -H cp /home/git/gitlab/config/unicorn.rb /home/git/gitlab/config/unicorn.rb.old
 sudo -u git -H cp /home/git/gitlab/config/unicorn.rb.example /home/git/gitlab/config/unicorn.rb
 
-#nginx
+# Nginx
 # Replace path from '/home/gitlab/' to '/home/git/'
 sudo vim /etc/nginx/sites-enabled/gitlab
 sudo service nginx restart
@@ -137,7 +137,7 @@ sudo service gitlab start
 
 # check if unicorn and sidekiq started
 # If not try to logout, also check replaced path from '/home/gitlab/' to '/home/git/'
-# in nginx, unicorn, init.d etc
+# in Nginx, unicorn, init.d etc
 ps aux | grep unicorn
 ps aux | grep sidekiq
 
diff --git a/doc/update/5.1-to-6.0.md b/doc/update/5.1-to-6.0.md
index a76b371e6d683bc17163bcec8799b782d23e4054..ef412b45695948d0e01940bf1b1aa5af107e8082 100644
--- a/doc/update/5.1-to-6.0.md
+++ b/doc/update/5.1-to-6.0.md
@@ -40,7 +40,7 @@ sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
 
 The migrations in this update are very sensitive to incomplete or inconsistent data. If you have a long-running GitLab installation and some of the previous upgrades did not work out 100% correct this may bite you now. The following can help you have a more smooth upgrade.
 
-### Find projets with invalid project names
+### Find projects with invalid project names
 
 #### MySQL
 Login to MySQL:
diff --git a/doc/update/6.1-to-6.2.md b/doc/update/6.1-to-6.2.md
index efa6e43124cb96ecbdbe86499d9e826e9edb1666..11b124cf263c4b2c3492c5a44e15892686483e7d 100644
--- a/doc/update/6.1-to-6.2.md
+++ b/doc/update/6.1-to-6.2.md
@@ -35,7 +35,7 @@ sudo -u git -H git checkout v1.7.9 # Addresses multiple critical security vulner
 ## 4. Install additional packages
 
 ```bash
-# Add support for lograte for better log file handling
+# Add support for logrotate for better log file handling
 sudo apt-get install logrotate
 ```
 
diff --git a/doc/update/6.x-or-7.x-to-7.7.md b/doc/update/6.x-or-7.x-to-7.7.md
index 0cbea5d59975fdc1aa9e31d9e4adbe8dfb890e5a..e9a0d3d4c655242ec7737290e1c6d54ba08be23e 100644
--- a/doc/update/6.x-or-7.x-to-7.7.md
+++ b/doc/update/6.x-or-7.x-to-7.7.md
@@ -84,7 +84,7 @@ sudo -u git -H git checkout 7-7-stable-ee
 ## 4. Install additional packages
 
 ```bash
-# Add support for lograte for better log file handling
+# Add support for logrotate for better log file handling
 sudo apt-get install logrotate
 
 # Install pkg-config and cmake, which is needed for the latest versions of rugged
@@ -220,13 +220,13 @@ mysql -u root -p
 # Convert all tables to use the InnoDB storage engine (added in GitLab 6.8)
 SELECT CONCAT('ALTER TABLE gitlabhq_production.', table_name, ' ENGINE=InnoDB;') AS 'Copy & run these SQL statements:' FROM information_schema.tables WHERE table_schema = 'gitlabhq_production' AND `ENGINE` <> 'InnoDB' AND `TABLE_TYPE` = 'BASE TABLE';
 
-# If previous query returned results, copy & run all outputed SQL statements
+# If previous query returned results, copy & run all shown SQL statements
 
 # Convert all tables to correct character set
 SET foreign_key_checks = 0;
 SELECT CONCAT('ALTER TABLE gitlabhq_production.', table_name, ' CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;') AS 'Copy & run these SQL statements:' FROM information_schema.tables WHERE table_schema = 'gitlabhq_production' AND `TABLE_COLLATION` <> 'utf8_unicode_ci' AND `TABLE_TYPE` = 'BASE TABLE';
 
-# If previous query returned results, copy & run all outputed SQL statements
+# If previous query returned results, copy & run all shown SQL statements
 
 # turn foreign key checks back on
 SET foreign_key_checks = 1;
diff --git a/doc/update/7.3-to-7.4.md b/doc/update/7.3-to-7.4.md
index 2466050ea4c4786cccb47460f79beffd4fa6f0b0..62bd98832c2e4ed150133e3a482cc4721563dca2 100644
--- a/doc/update/7.3-to-7.4.md
+++ b/doc/update/7.3-to-7.4.md
@@ -114,13 +114,13 @@ mysql -u root -p
 # Convert all tables to use the InnoDB storage engine (added in GitLab 6.8)
 SELECT CONCAT('ALTER TABLE gitlabhq_production.', table_name, ' ENGINE=InnoDB;') AS 'Copy & run these SQL statements:' FROM information_schema.tables WHERE table_schema = 'gitlabhq_production' AND `ENGINE` <> 'InnoDB' AND `TABLE_TYPE` = 'BASE TABLE';
 
-# If previous query returned results, copy & run all outputed SQL statements
+# If previous query returned results, copy & run all shown SQL statements
 
 # Convert all tables to correct character set
 SET foreign_key_checks = 0;
 SELECT CONCAT('ALTER TABLE gitlabhq_production.', table_name, ' CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;') AS 'Copy & run these SQL statements:' FROM information_schema.tables WHERE table_schema = 'gitlabhq_production' AND `TABLE_COLLATION` <> 'utf8_unicode_ci' AND `TABLE_TYPE` = 'BASE TABLE';
 
-# If previous query returned results, copy & run all outputed SQL statements
+# If previous query returned results, copy & run all shown SQL statements
 
 # turn foreign key checks back on
 SET foreign_key_checks = 1;
diff --git a/doc/update/README.md b/doc/update/README.md
index 30e9137d7b718451db043995f85cf2676fd83144..5380ddbd030334af46c9af2c45da66bc5b64024d 100644
--- a/doc/update/README.md
+++ b/doc/update/README.md
@@ -13,4 +13,4 @@ Depending on the installation method and your GitLab version, there are multiple
 
 ## Miscellaneous
 
-- [MySQL to PostgreSQL](mysql_to_postgresql.md) guides you through migrating your database from MySQL to PostrgreSQL.
+- [MySQL to PostgreSQL](mysql_to_postgresql.md) guides you through migrating your database from MySQL to PostgreSQL.
diff --git a/doc/workflow/gitlab_flow.md b/doc/workflow/gitlab_flow.md
index 1dbff60cbfde56a29fa1629ca5016de46afc9682..0e87dc74217d40e9df803c1b9b4988c12405f341 100644
--- a/doc/workflow/gitlab_flow.md
+++ b/doc/workflow/gitlab_flow.md
@@ -43,7 +43,7 @@ Since most tools automatically make the master branch the default one and displa
 The second problem of git flow is the complexity introduced by the hotfix and release branches.
 These branches can be a good idea for some organizations but are overkill for the vast majority of them.
 Nowadays most organizations practice continuous delivery which means that your default branch can be deployed.
-This means that hotfixed and release branches can be prevented including all the ceremony they introduce.
+This means that hotfix and release branches can be prevented including all the ceremony they introduce.
 An example of this ceremony is the merging back of release branches.
 Though specialized tools do exist to solve this, they require documentation and add complexity.
 Frequently developers make a mistake and for example changes are only merged into master and not into the develop branch.
@@ -95,12 +95,12 @@ An 'extreme' version of environment branches are setting up an environment for e
 
 ## Release branches with GitLab flow
 
-![Master and multiple release branches that vary in length with cherrypicks from master](release_branches.png)
+![Master and multiple release branches that vary in length with cherry-picks from master](release_branches.png)
 
 Only in case you need to release software to the outside world you need to work with release branches.
 In this case, each branch contains a minor version (2-3-stable, 2-4-stable, etc.).
 The stable branch uses master as a starting point and is created as late as possible.
-By branching as late as possible you minimize the time you have to apply bugfixes to multiple branches.
+By branching as late as possible you minimize the time you have to apply bug fixes to multiple branches.
 After a release branch is announced, only serious bug fixes are included in the release branch.
 If possible these bug fixes are first merged into master and then cherry-picked into the release branch.
 This way you can't forget to cherry-pick them into master and encounter the same bug on subsequent releases.
@@ -177,7 +177,7 @@ In GitLab this creates a comment in the issue that the merge requests mentions t
 And the merge request shows the linked issues.
 These issues are closed once code is merged into the default branch.
 
-If you only want to make the reference without closing the issue you can also just mention it: "Ducktyping is preferred. #12".
+If you only want to make the reference without closing the issue you can also just mention it: "Duck typing is preferred. #12".
 
 If you have an issue that spans across multiple repositories, the best thing is to create an issue for each repository and link all issues to a parent issue.
 
diff --git a/doc/workflow/migrating_from_svn.md b/doc/workflow/migrating_from_svn.md
index 207e36418024dfb0b939cd15077696ea5152017f..485db4834e97c635d546cbfeb02c14e893051cfd 100644
--- a/doc/workflow/migrating_from_svn.md
+++ b/doc/workflow/migrating_from_svn.md
@@ -3,7 +3,7 @@
 SVN stands for Subversion and is a version control system (VCS).
 Git is a distributed version control system.
 
-There are some major differences between the two, for more information consult your favourite search engine.
+There are some major differences between the two, for more information consult your favorite search engine.
 
 Git has tools for migrating SVN repositories to git, namely `git svn`. You can read more about this at
 [git documentation pages](http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion).
diff --git a/doc/workflow/notifications.md b/doc/workflow/notifications.md
index 3c3ce162df5c27567e529e7c48f5f4ff651acce9..17215de677e153d2aedfae3f91f7f51b0a57f2f1 100644
--- a/doc/workflow/notifications.md
+++ b/doc/workflow/notifications.md
@@ -24,14 +24,14 @@ Each of these settings have levels of notification:
 #### Global Settings
 
 Global Settings are at the bottom of the hierarchy.
-Any setting set here will be overriden by a setting at the group or a project level.
+Any setting set here will be overridden by a setting at the group or a project level.
 
 Group or Project settings can use `global` notification setting which will then use
 anything that is set at Global Settings.
 
 #### Group Settings
 
-Group Settings are taking presedence over Global Settings but are on a level below Project Settings.
+Group Settings are taking precedence over Global Settings but are on a level below Project Settings.
 This means that you can set a different level of notifications per group while still being able
 to have a finer level setting per project.
 Organization like this is suitable for users that belong to different groups but don't have the
@@ -39,7 +39,7 @@ same need for being notified for every group they are member of.
 
 #### Project Settings
 
-Project Settings are at the top level and any setting placed at this level will take presedence of any
+Project Settings are at the top level and any setting placed at this level will take precedence of any
 other setting.
 This is suitable for users that have different needs for notifications per project basis.