Update with suggestionsdocs-capitalization-2

Change list to codeblock and simplify issue links

3 files changed, 10 insertions, 8 deletions

diff --git a/doc/development/background_migrations.md b/doc/development/background_migrations.md
index 868dd68fb7e..3fd95537eaa 100644
--- a/doc/development/background_migrations.md
+++ b/doc/development/background_migrations.md
@@ -294,7 +294,7 @@ to migrate you database down and up, which can result in other background
 migrations being called. That means that using `spy` test doubles with
 `have_received` is encouraged, instead of using regular test doubles, because
 your expectations defined in a `it` block can conflict with what is being
-called in RSpec hooks. See [GitLab CE issue #35351][issue-rspec-hooks]
+called in RSpec hooks. See [issue #35351][issue-rspec-hooks]
 for more details.
 
 ## Best practices
diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md
index 7c8a12a5748..f2412c249c1 100644
--- a/doc/development/elasticsearch.md
+++ b/doc/development/elasticsearch.md
@@ -40,9 +40,11 @@ There is no need to install any plugins
 
 If you're interested on working with the new beta repo indexer, all you need to do is:
 
-- `git clone git@gitlab.com:gitlab-org/gitlab-elasticsearch-indexer.git`
-- `make`
-- `make install`
+```sh
+git clone git@gitlab.com:gitlab-org/gitlab-elasticsearch-indexer.git
+make
+make install
+```
 
 this adds `gitlab-elasticsearch-indexer` to `$GOPATH/bin`, please make sure that is in your `$PATH`. After that GitLab will find it and you'll be able to enable it in the admin settings area.
 
diff --git a/doc/development/filtering_by_label.md b/doc/development/filtering_by_label.md
index 60af3fd6d40..dd8944ff1c8 100644
--- a/doc/development/filtering_by_label.md
+++ b/doc/development/filtering_by_label.md
@@ -40,13 +40,13 @@ In particular, note that:
 
 This is more complicated than is ideal. It makes the query construction more
 prone to errors (such as
-[GitLab CE issue #15557](https://gitlab.com/gitlab-org/gitlab-ce/issues/15557)).
+[issue #15557](https://gitlab.com/gitlab-org/gitlab-ce/issues/15557)).
 
 ## Attempt A: WHERE EXISTS
 
 ### Attempt A1: use multiple subqueries with WHERE EXISTS
 
-In [GitLab CE issue #37137](https://gitlab.com/gitlab-org/gitlab-ce/issues/37137)
+In [issue #37137](https://gitlab.com/gitlab-org/gitlab-ce/issues/37137)
 and its associated [merge request](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14022),
 we tried to replace the `GROUP BY` with multiple uses of `WHERE EXISTS`. For the
 example above, this would give:
@@ -83,7 +83,7 @@ Having [removed MySQL support in GitLab 12.1](https://about.gitlab.com/2019/06/2
 using [Postgres's arrays](https://www.postgresql.org/docs/9.6/arrays.html) became more
 tractable as we didn't have to support two databases. We discussed denormalizing
 the `label_links` table for querying in
-[GitLab CE issue #49651](https://gitlab.com/gitlab-org/gitlab-ce/issues/49651),
+[issue #49651](https://gitlab.com/gitlab-org/gitlab-ce/issues/49651),
 with two options: label IDs and titles.
 
 We can think of both of those as array columns on `issues`, `merge_requests`,
@@ -147,7 +147,7 @@ WHERE
     label_titles @> ARRAY['Plan', 'backend']
 ```
 
-And our [tests in GitLab CE issue #49651](https://gitlab.com/gitlab-org/gitlab-ce/issues/49651#note_188777346)
+And our [tests in issue #49651](https://gitlab.com/gitlab-org/gitlab-ce/issues/49651#note_188777346)
 showed that this could be fast.
 
 However, at present, the disadvantages outweigh the advantages.