Make unordered lists conform to styleguide

- Also makes other minor Markdown fixes that were near the main fixes.

1 files changed, 13 insertions, 13 deletions

diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md
index fa58d0ef15f..06ef6988014 100644
--- a/doc/administration/integration/terminal.md
+++ b/doc/administration/integration/terminal.md
@@ -14,17 +14,17 @@ A detailed overview of the architecture of web terminals and how they work
 can be found in [this document](https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/doc/terminal.md).
 In brief:
 
-* GitLab relies on the user to provide their own Kubernetes credentials, and to
+- GitLab relies on the user to provide their own Kubernetes credentials, and to
   appropriately label the pods they create when deploying.
-* When a user navigates to the terminal page for an environment, they are served
+- When a user navigates to the terminal page for an environment, they are served
   a JavaScript application that opens a WebSocket connection back to GitLab.
-* The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
+- The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
    rather than the Rails application server.
-* Workhorse queries Rails for connection details and user permissions; Rails
-  queries Kubernetes for them in the background, using [Sidekiq](../troubleshooting/sidekiq.md)
-* Workhorse acts as a proxy server between the user's browser and the Kubernetes
+- Workhorse queries Rails for connection details and user permissions. Rails
+  queries Kubernetes for them in the background using [Sidekiq](../troubleshooting/sidekiq.md).
+- Workhorse acts as a proxy server between the user's browser and the Kubernetes
   API, passing WebSocket frames between the two.
-* Workhorse regularly polls Rails, terminating the WebSocket connection if the
+- Workhorse regularly polls Rails, terminating the WebSocket connection if the
   user no longer has permission to access the terminal, or if the connection
   details have changed.
 
@@ -40,10 +40,10 @@ However, if you run a [load balancer](../high_availability/load_balancer.md) in
 front of GitLab, you may need to make some changes to your configuration. These
 guides document the necessary steps for a selection of popular reverse proxies:
 
-* [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
-* [NGINX](https://www.nginx.com/blog/websocket-nginx/)
-* [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/)
-* [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
+- [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
+- [NGINX](https://www.nginx.com/blog/websocket-nginx/)
+- [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/)
+- [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
 
 Workhorse won't let WebSocket requests through to non-WebSocket endpoints, so
 it's safe to enable support for these headers globally. If you'd rather had a
@@ -60,8 +60,8 @@ 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:
 
-* 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
+- 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
   `Connection` and `Upgrade` lines.
 
 For your own load balancer, just reverse the configuration changes recommended