Merge branch 'master' into feature/gb/manual-actions-protected-branches-permissions

* master: (103 commits)
  Include missing project attributes to Import/Export
  Create the rest of the wiki docs
  Fill in information about creating the wiki Home page
  Move wiki doc to its own index page
  Create initial file for Wiki documentation
  Default to null user when asignee is unselected
  Re-enable ref operations with gitaly after not-found fix
  #31560 Add repo parameter to gitaly:install and workhorse:install
  Remove N+1 queries when checking nodes visible to user
  Don't validate reserved words if the format doesn't match
  Revert "Shorten and improve some job names"
  Remove unused initializer
  DRY the `<<: *except-docs` a bit in `.gitlab-ci.yml`
  Make the static-analysis job be run for docs branches too
  Add download_snippet_path helper
  Refresh the markdown cache if it was `nil`
  Add some documentation for the new migration helpers
  Update comments
  Display comments for personal snippets
  Update docs on creating a project
  ...

25 files changed, 315 insertions, 32 deletions

diff --git a/doc/README.md b/doc/README.md
index 6406040da4b..4397465bd3d 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -92,7 +92,7 @@ Take a step ahead and dive into GitLab's advanced features.
 
 - [GitLab Pages](user/project/pages/index.md): Build, test, and deploy your static website with GitLab Pages.
 - [Snippets](user/snippets.md): Snippets allow you to create little bits of code.
-- [Wikis](workflow/project_features.md#wiki): Enhance your repository documentation with built-in wikis.
+- [Wikis](user/project/wiki/index.md): Enhance your repository documentation with built-in wikis.
 
 ### Continuous Integration, Delivery, and Deployment
 
diff --git a/doc/administration/high_availability/load_balancer.md b/doc/administration/high_availability/load_balancer.md
index d9ca74ca1a3..359de0efadb 100644
--- a/doc/administration/high_availability/load_balancer.md
+++ b/doc/administration/high_availability/load_balancer.md
@@ -13,7 +13,7 @@ you need to use with GitLab.
 | LB Port | Backend Port | Protocol        |
 | ------- | ------------ | --------------- |
 | 80      | 80           | HTTP  [^1]      |
-| 443     | 443          | HTTPS [^1] [^2] |
+| 443     | 443          | TCP or HTTPS [^1] [^2] |
 | 22      | 22           | TCP             |
 
 ## GitLab Pages Ports
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md
index 3b5ee86b68b..91e844c7b42 100644
--- a/doc/administration/integration/terminal.md
+++ b/doc/administration/integration/terminal.md
@@ -32,7 +32,7 @@ In brief:
 
 As web terminals use WebSockets, every HTTP/HTTPS reverse proxy in front of
 Workhorse needs to be configured to pass the `Connection` and `Upgrade` headers
-through to the next one in the chain. If you installed Gitlab using Omnibus, or
+through to the next one in the chain. If you installed GitLab using Omnibus, or
 from source, starting with GitLab 8.15, this should be done by the default
 configuration, so there's no need for you to do anything.
 
@@ -58,7 +58,7 @@ document for more details.
 If you'd like to disable web terminal support in GitLab, just stop passing
 the `Connection` and `Upgrade` hop-by-hop headers in the *first* HTTP reverse
 proxy in the chain. For most users, this will be the NGINX server bundled with
-Omnibus Gitlab, in which case, you need to:
+Omnibus GitLab, in which case, you need to:
 
 * Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file
 * Ensure the whole block is uncommented, and then comment out or remove the
diff --git a/doc/ci/img/pipelines_grouped.png b/doc/ci/img/pipelines_grouped.png
new file mode 100644
index 00000000000..06f52e03320
--- /dev/null
+++ b/doc/ci/img/pipelines_grouped.png
diff --git a/doc/ci/img/pipelines_index.png b/doc/ci/img/pipelines_index.png
new file mode 100644
index 00000000000..3b522a9c5e4
--- /dev/null
+++ b/doc/ci/img/pipelines_index.png
diff --git a/doc/ci/img/pipelines_mini_graph.png b/doc/ci/img/pipelines_mini_graph.png
new file mode 100644
index 00000000000..042c8ffeef5
--- /dev/null
+++ b/doc/ci/img/pipelines_mini_graph.png
diff --git a/doc/ci/img/pipelines_mini_graph_simple.png b/doc/ci/img/pipelines_mini_graph_simple.png
new file mode 100644
index 00000000000..eb36c09b2d4
--- /dev/null
+++ b/doc/ci/img/pipelines_mini_graph_simple.png
diff --git a/doc/ci/img/pipelines_mini_graph_sorting.png b/doc/ci/img/pipelines_mini_graph_sorting.png
new file mode 100644
index 00000000000..3a4e5453360
--- /dev/null
+++ b/doc/ci/img/pipelines_mini_graph_sorting.png
diff --git a/doc/ci/pipelines.md b/doc/ci/pipelines.md
index db92a4b0d80..5a2b61fb0cb 100644
--- a/doc/ci/pipelines.md
+++ b/doc/ci/pipelines.md
@@ -1,7 +1,6 @@
 # Introduction to pipelines and jobs
 
->**Note:**
-Introduced in GitLab 8.8.
+> Introduced in GitLab 8.8.
 
 ## Pipelines
 
@@ -9,11 +8,17 @@ A pipeline is a group of [jobs][] that get executed in [stages][](batches).
 All of the jobs in a stage are executed in parallel (if there are enough
 concurrent [Runners]), and if they all succeed, the pipeline moves on to the
 next stage. If one of the jobs fails, the next stage is not (usually)
-executed.
+executed. You can access the pipelines page in your project's **Pipelines** tab.
+
+In the following image you can see that the pipeline consists of four stages
+(`build`, `test`, `staging`, `production`) each one having one or more jobs.
+
+>**Note:**
+GitLab capitalizes the stages' names when shown in the [pipeline graphs](#pipeline-graphs).
 
 ![Pipelines example](img/pipelines.png)
 
-## Types of Pipelines
+## Types of pipelines
 
 There are three types of pipelines that often use the single shorthand of "pipeline". People often talk about them as if each one is "the" pipeline, but really, they're just pieces of a single, comprehensive pipeline.
 
@@ -23,7 +28,7 @@ There are three types of pipelines that often use the single shorthand of "pipel
 2. **Deploy Pipeline**: Deploy stage(s) defined in `.gitlab-ci.yml` The flow of deploying code to servers through various stages: e.g. development to staging to production
 3. **Project Pipeline**: Cross-project CI dependencies [triggered via API][triggers], particularly for micro-services, but also for complicated build dependencies: e.g. api -> front-end, ce/ee -> omnibus.
 
-## Development Workflows
+## Development workflows
 
 Pipelines accommodate several development workflows:
 
@@ -45,18 +50,141 @@ confused with a `build` job or `build` stage.
 Pipelines are defined in `.gitlab-ci.yml` by specifying [jobs] that run in
 [stages].
 
-See full [documentation](yaml/README.md#jobs).
+See the reference [documentation for jobs](yaml/README.md#jobs).
 
 ## Seeing pipeline status
 
-You can find the current and historical pipeline runs under **Pipelines** for
-your project.
+You can find the current and historical pipeline runs under your project's
+**Pipelines** tab. Clicking on a pipeline will show the jobs that were run for
+that pipeline.
+
+![Pipelines index page](img/pipelines_index.png)
 
 ## Seeing job status
 
-Clicking on a pipeline will show the jobs that were run for that pipeline.
+When you visit a single pipeline you can see the related jobs for that pipeline.
 Clicking on an individual job will show you its job trace, and allow you to
-cancel the job, retry it,  or erase the job trace.
+cancel the job, retry it, or erase the job trace.
+
+![Pipelines example](img/pipelines.png)
+
+## Pipeline graphs
+
+> [Introduced][ce-5742] in GitLab 8.11.
+
+Pipelines can be complex structures with many sequential and parallel jobs.
+To make it a little easier to see what is going on, you can view a graph
+of a single pipeline and its status.
+
+A pipeline graph can be shown in two different ways depending on what page you
+are on.
+
+---
+
+The regular pipeline graph that shows the names of the jobs of each stage can
+be found when you are on a [single pipeline page](#seeing-pipeline-status).
+
+![Pipelines example](img/pipelines.png)
+
+Then, there is the pipeline mini graph which takes less space and can give you a
+quick glance if all jobs pass or something failed. The pipeline mini graph can
+be found when you visit:
+
+- the pipelines index page
+- a single commit page
+- a merge request page
+
+That way, you can see all related jobs for a single commit and the net result
+of each stage of your pipeline. This allows you to quickly see what failed and
+fix it. Stages in pipeline mini graphs are collapsible. Hover your mouse over
+them and click to expand their jobs.
+
+| **Mini graph** | **Mini graph expanded** |
+| :------------: | :---------------------: |
+| ![Pipelines mini graph](img/pipelines_mini_graph_simple.png) | ![Pipelines mini graph extended](img/pipelines_mini_graph.png) |
+
+### Grouping similar jobs in the pipeline graph
+
+> [Introduced][ce-6242] in GitLab 8.12.
+
+If you have many similar jobs, your pipeline graph becomes very long and hard
+to read. For that reason, similar jobs can automatically be grouped together.
+If the job names are formatted in certain ways, they will be collapsed into
+a single group in regular pipeline graphs (not the mini graphs).
+You'll know when a pipeline has grouped jobs if you don't see the retry or
+cancel button inside them. Hovering over them will show the number of grouped
+jobs. Click to expand them.
+
+![Grouped pipelines](img/pipelines_grouped.png)
+
+The basic requirements is that there are two numbers separated with one of
+the following (you can even use them interchangeably):
+
+- a space
+- a backslash (`/`)
+- a colon (`:`)
+
+>**Note:**
+More specifically, [it uses][regexp] this regular expression: `\d+[\s:\/\\]+\d+\s*`.
+
+The jobs will be ordered by comparing those two numbers from left to right. You
+usually want the first to be the index and the second the total.
+
+For example, the following jobs will be grouped under a job named `test`:
+
+- `test 0 3` => `test`
+- `test 1 3` => `test`
+- `test 2 3` => `test`
+
+The following jobs will be grouped under a job named `test ruby`:
+
+- `test 1:2 ruby` => `test ruby`
+- `test 2:2 ruby` => `test ruby`
+
+The following jobs will be grouped under a job named `test ruby` as well:
+
+- `1/3 test ruby` => `test ruby`
+- `2/3 test ruby` => `test ruby`
+- `3/3 test ruby` => `test ruby`
+
+### Manual actions from the pipeline graph
+
+> [Introduced][ce-7931] in GitLab 8.15.
+
+[Manual actions][manual] allow you to require manual interaction before moving
+forward with a particular job in CI. Your entire pipeline can run automatically,
+but the actual [deploy to production][env-manual] will require a click.
+
+You can do this straight from the pipeline graph. Just click on the play button
+to execute that particular job. For example, in the image below, the `production`
+stage has a job with a manual action.
+
+![Pipelines example](img/pipelines.png)
+
+### Ordering of jobs in pipeline graphs
+
+**Regular pipeline graph**
+
+In the single pipeline page, jobs are sorted by name.
+
+**Mini pipeline graph**
+
+> [Introduced][ce-9760] in GitLab 9.0.
+
+In the pipeline mini graphs, the jobs are sorted first by severity and then
+by name. The order of severity is:
+
+- failed
+- warning
+- pending
+- running
+- manual
+- canceled
+- success
+- skipped
+- created
+
+![Pipeline mini graph sorting](img/pipelines_mini_graph_sorting.png)
 
 ## How the pipeline duration is calculated
 
@@ -96,7 +224,14 @@ respective link in the [Pipelines settings] page.
 
 [jobs]: #jobs
 [jobs-yaml]: yaml/README.md#jobs
+[manual]: yaml/README.md#manual
+[env-manual]: environments.md#manually-deploying-to-environments
 [stages]: yaml/README.md#stages
 [runners]: runners/README.html
 [pipelines settings]: ../user/project/pipelines/settings.md
 [triggers]: triggers/README.md
+[ce-5742]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5742
+[ce-6242]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6242
+[ce-7931]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7931
+[ce-9760]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9760
+[regexp]: https://gitlab.com/gitlab-org/gitlab-ce/blob/2f3dc314f42dbd79813e6251792853bc231e69dd/app/models/commit_status.rb#L99
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 3e8b709c18f..77ba2a5fd87 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -270,3 +270,28 @@ end
 
 When doing so be sure to explicitly set the model's table name so it's not
 derived from the class name or namespace.
+
+### Renaming reserved paths
+
+When a new route for projects is introduced that could conflict with any
+existing records. The path for this records should be renamed, and the
+related data should be moved on disk.
+
+Since we had to do this a few times already, there are now some helpers to help
+with this.
+
+To use this you can include `Gitlab::Database::RenameReservedPathsMigration::V1`
+in your migration. This will provide 3 methods which you can pass one or more
+paths that need to be rejected.
+
+**`rename_root_paths`**: This will rename the path of all _namespaces_ with the
+given name that don't have a `parent_id`.
+
+**`rename_child_paths`**: This will rename the path of all _namespaces_ with the
+given name that have a `parent_id`.
+
+**`rename_wildcard_paths`**: This will rename the path of all _projects_, and all
+_namespaces_ that have a `project_id`.
+
+The `path` column for these rows will be renamed to their previous value followed
+by an integer. For example: `users` would turn into `users0`
diff --git a/doc/development/testing.md b/doc/development/testing.md
index 9b0b9808827..6d8b846d27f 100644
--- a/doc/development/testing.md
+++ b/doc/development/testing.md
@@ -188,7 +188,8 @@ Please consult the [dedicated "Frontend testing" guide](./fe_guide/testing.md).
 ### General Guidelines
 
 - Use a single, top-level `describe ClassName` block.
-- Use `described_class` instead of repeating the class name being described.
+- Use `described_class` instead of repeating the class name being described
+  (_this is enforced by RuboCop_).
 - Use `.method` to describe class methods and `#method` to describe instance
   methods.
 - Use `context` to test branching logic.
@@ -197,7 +198,7 @@ Please consult the [dedicated "Frontend testing" guide](./fe_guide/testing.md).
 - Don't `describe` symbols (see [Gotchas](gotchas.md#dont-describe-symbols)).
 - Don't assert against the absolute value of a sequence-generated attribute (see [Gotchas](gotchas.md#dont-assert-against-the-absolute-value-of-a-sequence-generated-attribute)).
 - Don't supply the `:each` argument to hooks since it's the default.
-- Prefer `not_to` to `to_not` (_this is enforced by Rubocop_).
+- Prefer `not_to` to `to_not` (_this is enforced by RuboCop_).
 - Try to match the ordering of tests to the ordering within the class.
 - Try to follow the [Four-Phase Test][four-phase-test] pattern, using newlines
   to separate phases.
diff --git a/doc/gitlab-basics/create-project.md b/doc/gitlab-basics/create-project.md
index 1c549844ee1..2513f4b420a 100644
--- a/doc/gitlab-basics/create-project.md
+++ b/doc/gitlab-basics/create-project.md
@@ -1,24 +1,28 @@
 # How to create a project in GitLab
 
-There are two ways to create a new project in GitLab.
-
-1. While in your dashboard, you can create a new project using the **New project**
-   green button or you can use the cross icon in the upper right corner next to
-   your avatar which is always visible.
+1. In your dashboard, click the green **New project** button or use the plus
+   icon in the upper right corner of the navigation bar.
 
     ![Create a project](img/create_new_project_button.png)
 
-1. From there you can see several options.
+1. This opens the **New project** page.
 
     ![Project information](img/create_new_project_info.png)
 
-1. Fill out the information:
-
-  1. "Project name" is the name of your project (you can't use special characters,
-     but you can use spaces, hyphens, underscores or even emojis).
-  1. The "Project description" is optional and will be shown in your project's
-     dashboard so others can briefly understand what your project is about.
-  1. Select a [visibility level](../public_access/public_access.md).
-  1. You can also [import your existing projects](../workflow/importing/README.md).
-
-1. Finally, click **Create project**.
+1. Provide the following information:
+    - Enter the name of your project in the **Project name** field. You can't use
+      special characters, but you can use spaces, hyphens, underscores or even
+      emoji.
+    - If you have a project in a different repository, you can [import it] by
+      clicking an **Import project from** button provided this is enabled in
+      your GitLab instance. Ask your administrator if not.
+    - The **Project description (optional)** field enables you to enter a
+      description for your project's dashboard, which will help others
+      understand what your project is about. Though it's not required, it's a good
+      idea to fill this in.
+    - Changing the **Visibility Level** modifies the project's
+      [viewing and access rights](../public_access/public_access.md) for users.
+
+1. Click **Create project**.
+
+[import it]: ../workflow/importing/README.md
diff --git a/doc/gitlab-basics/img/create_new_project_button.png b/doc/gitlab-basics/img/create_new_project_button.png
index 8d7a69e55ed..567f104880f 100644
--- a/doc/gitlab-basics/img/create_new_project_button.png
+++ b/doc/gitlab-basics/img/create_new_project_button.png
diff --git a/doc/install/installation.md b/doc/install/installation.md
index b6bbc2a0af6..dc807d93bbb 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -423,6 +423,11 @@ which is the recommended location.
 
     sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse]" RAILS_ENV=production
 
+You can specify a different Git repository by providing it as an extra paramter:
+
+    sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse,https://example.com/gitlab-workhorse.git]" RAILS_ENV=production
+
+
 ### Initialize Database and Activate Advanced Features
 
     sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production
@@ -466,6 +471,12 @@ with setting up Gitaly until you upgrade to GitLab 9.2 or later.
     # Fetch Gitaly source with Git and compile with Go
     sudo -u git -H bundle exec rake "gitlab:gitaly:install[/home/git/gitaly]" RAILS_ENV=production
 
+You can specify a different Git repository by providing it as an extra paramter:
+
+    sudo -u git -H bundle exec rake "gitlab:gitaly:install[/home/git/gitaly,https://example.com/gitaly.git]" RAILS_ENV=production
+
+Next, make sure gitaly configured:
+
     # Restrict Gitaly socket access
     sudo chmod 0700 /home/git/gitlab/tmp/sockets/private
     sudo chown git /home/git/gitlab/tmp/sockets/private
diff --git a/doc/update/8.10-to-8.11.md b/doc/update/8.10-to-8.11.md
index e5e3cd395df..e538983e603 100644
--- a/doc/update/8.10-to-8.11.md
+++ b/doc/update/8.10-to-8.11.md
@@ -49,6 +49,8 @@ sudo gem install bundler --no-ri --no-rdoc
 ### 4. Get latest code
 
 ```bash
+cd /home/git/gitlab
+
 sudo -u git -H git fetch --all
 sudo -u git -H git checkout -- db/schema.rb # local changes will be restored automatically
 ```
diff --git a/doc/update/8.11-to-8.12.md b/doc/update/8.11-to-8.12.md
index d6b3b0ffa5a..604166beb56 100644
--- a/doc/update/8.11-to-8.12.md
+++ b/doc/update/8.11-to-8.12.md
@@ -49,6 +49,8 @@ sudo gem install bundler --no-ri --no-rdoc
 ### 4. Get latest code
 
 ```bash
+cd /home/git/gitlab
+
 sudo -u git -H git fetch --all
 sudo -u git -H git checkout -- db/schema.rb # local changes will be restored automatically
 ```
diff --git a/doc/update/8.12-to-8.13.md b/doc/update/8.12-to-8.13.md
index ed0e668d854..d83965131f5 100644
--- a/doc/update/8.12-to-8.13.md
+++ b/doc/update/8.12-to-8.13.md
@@ -49,6 +49,8 @@ sudo gem install bundler --no-ri --no-rdoc
 ### 4. Get latest code
 
 ```bash
+cd /home/git/gitlab
+
 sudo -u git -H git fetch --all
 sudo -u git -H git checkout -- db/schema.rb # local changes will be restored automatically
 ```
diff --git a/doc/update/8.13-to-8.14.md b/doc/update/8.13-to-8.14.md
index aa1c659717e..aaadcec8ac0 100644
--- a/doc/update/8.13-to-8.14.md
+++ b/doc/update/8.13-to-8.14.md
@@ -49,6 +49,8 @@ sudo gem install bundler --no-ri --no-rdoc
 ### 4. Get latest code
 
 ```bash
+cd /home/git/gitlab
+
 sudo -u git -H git fetch --all
 sudo -u git -H git checkout -- db/schema.rb # local changes will be restored automatically
 ```
diff --git a/doc/user/project/wiki/img/wiki_create_home_page.png b/doc/user/project/wiki/img/wiki_create_home_page.png
new file mode 100644
index 00000000000..f50f564034c
--- /dev/null
+++ b/doc/user/project/wiki/img/wiki_create_home_page.png
diff --git a/doc/user/project/wiki/img/wiki_create_new_page.png b/doc/user/project/wiki/img/wiki_create_new_page.png
new file mode 100644
index 00000000000..c19124a8923
--- /dev/null
+++ b/doc/user/project/wiki/img/wiki_create_new_page.png
diff --git a/doc/user/project/wiki/img/wiki_create_new_page_modal.png b/doc/user/project/wiki/img/wiki_create_new_page_modal.png
new file mode 100644
index 00000000000..ece437967dc
--- /dev/null
+++ b/doc/user/project/wiki/img/wiki_create_new_page_modal.png
diff --git a/doc/user/project/wiki/img/wiki_page_history.png b/doc/user/project/wiki/img/wiki_page_history.png
new file mode 100644
index 00000000000..0e6af1b468d
--- /dev/null
+++ b/doc/user/project/wiki/img/wiki_page_history.png
diff --git a/doc/user/project/wiki/img/wiki_sidebar.png b/doc/user/project/wiki/img/wiki_sidebar.png
new file mode 100644
index 00000000000..59814e2a06e
--- /dev/null
+++ b/doc/user/project/wiki/img/wiki_sidebar.png
diff --git a/doc/user/project/wiki/index.md b/doc/user/project/wiki/index.md
new file mode 100644
index 00000000000..e9ee1abc6c1
--- /dev/null
+++ b/doc/user/project/wiki/index.md
@@ -0,0 +1,97 @@
+# Wiki
+
+A separate system for documentation called Wiki, is built right into each
+GitLab project. It is enabled by default on all new projects and you can find
+it under **Wiki** in your project.
+
+Wikis are very convenient if you don't want to keep you documentation in your
+repository, but you do want to keep it in the same project where your code
+resides.
+
+You can create Wiki pages in the web interface or
+[locally using Git](#adding-and-editing-wiki-pages-locally) since every Wiki is
+a separate Git repository.
+
+>**Note:**
+A [permission level][permissions] of **Guest** is needed to view a Wiki and
+**Developer** is needed to create and edit Wiki pages.
+
+## First time creating the Home page
+
+The first time you visit a Wiki, you will be directed to create the Home page.
+The Home page is necessary to be created since it serves as the landing page
+when viewing a Wiki. You only have to fill in the **Content** section and click
+**Create page**. You can always edit it later, so go ahead and write a welcome
+message.
+
+![New home page](img/wiki_create_home_page.png)
+
+## Creating a new wiki page
+
+Create a new page by clicking the **New page** button that can be found
+in all wiki pages. You will be asked to fill in the page name from which GitLab
+will create the path to the page. You can specify a full path for the new file
+and any missing directories will be created automatically.
+
+![New page modal](img/wiki_create_new_page_modal.png)
+
+Once you enter the page name, it's time to fill in its content. GitLab wikis
+support Markdown, RDoc and AsciiDoc. For Markdown based pages, all the
+[Markdown features](../../markdown.md) are supported and for links there is
+some [wiki specific](../../markdown.md#wiki-specific-markdown) behavior.
+
+>**Note:**
+The wiki is based on a Git repository and contains only text files. Uploading
+files via the web interface will upload them in GitLab itself, and they will
+not be available if you clone the wiki repo locally.
+
+In the web interface the commit message is optional, but the GitLab Wiki is
+based on Git and needs a commit message, so one will be created for you if you
+do not enter one.
+
+When you're ready, click the **Create page** and the new page will be created.
+
+![New page](img/wiki_create_new_page.png)
+
+## Editing a wiki page
+
+To edit a page, simply click on the **Edit** button. From there on, you can
+change its content. When done, click **Save changes** for the changes to take
+effect.
+
+## Deleting a wiki page
+
+You can find the **Delete** button only when editing a page. Click on it and
+confirm you want the page to be deleted.
+
+## Viewing a list of all created wiki pages
+
+Every wiki has a sidebar from which a short list of the created pages can be
+found. The list is ordered alphabetically.
+
+![Wiki sidebar](img/wiki_sidebar.png)
+
+If you have many pages, not all will be listed in the sidebar. Click on
+**More pages** to see all of them.
+
+## Viewing the history of a wiki page
+
+The changes of a wiki page over time are recorded in the wiki's Git repository,
+and you can view them by clicking the **Page history** button.
+
+From the history page you can see the revision of the page (Git commit SHA), its
+author, the commit message, when it was last updated and the page markup format.
+To see how a previous version of the page looked like, click on a revision
+number.
+
+![Wiki page history](img/wiki_page_history.png)
+
+## Adding and editing wiki pages locally
+
+Since wikis are based on Git repositories, you can clone them locally and edit
+them like you would do with every other Git repository.
+
+On the right sidebar, click on **Clone repository** and follow the on-screen
+instructions.
+
+[permissions]: ../../permissions.md
diff --git a/doc/workflow/project_features.md b/doc/workflow/project_features.md
index f19e7df8c9a..3f5de2bd4b1 100644
--- a/doc/workflow/project_features.md
+++ b/doc/workflow/project_features.md
@@ -26,6 +26,8 @@ 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.
 
+[Read more about Wikis.](../user/project/wiki/index.md)
+
 ## Snippets
 
 Snippets are little bits of code or text.