Fix a number of discovered typos, capitalization of developer and

product names, plus a couple of instances of bad Markdown markup.

3 files changed, 8 insertions, 8 deletions

diff --git a/doc/workflow/gitlab_flow.md b/doc/workflow/gitlab_flow.md
index 1dbff60cbfd..0e87dc74217 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 207e3641802..485db4834e9 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 3c3ce162df5..17215de677e 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.