Fix kramdown link warnings

Changes are required to clean up Kramdown warnings that occur when
building the doc site.

doc/administration/geo/replication/database.md

@@ -35,7 +35,7 @@ The following guide assumes that:
 
 - You are using Omnibus and therefore you are using PostgreSQL 9.6 or later
   which includes the [`pg_basebackup` tool](https://www.postgresql.org/docs/9.6/app-pgbasebackup.html) and improved
-  [Foreign Data Wrapper][FDW](https://www.postgresql.org/docs/9.6/postgres-fdw.html) support.
+  [Foreign Data Wrapper](https://www.postgresql.org/docs/9.6/postgres-fdw.html) support.
 - You have a **primary** node already set up (the GitLab server you are
   replicating from), running Omnibus' PostgreSQL (or equivalent version), and
   you have a new **secondary** server set up with the same versions of the OS,

doc/development/experiment_guide/index.md

@@ -24,7 +24,7 @@ The author then adds a comment to this piece of code and adds a link to the issu
 
 ## How to create an A/B test
 
-- [ ] Add the experiment to the `Gitlab::Experimentation::EXPERIMENTS` hash in [`experimentation.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib%2Fgitlab%2Fexperimentation.rb):
+- Add the experiment to the `Gitlab::Experimentation::EXPERIMENTS` hash in [`experimentation.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib%2Fgitlab%2Fexperimentation.rb):
 
   ```ruby
   EXPERIMENTS = {
@@ -40,7 +40,7 @@ The author then adds a comment to this piece of code and adds a link to the issu
   }.freeze
   ```
 
-- [ ] Use the experiment in a controller:
+- Use the experiment in a controller:
 
   ```ruby
   class RegistrationController < Applicationcontroller
@@ -55,8 +55,8 @@ The author then adds a comment to this piece of code and adds a link to the issu
   end
   ```
 
-- [ ] Track necessary events. See the [event tracking guide](../event_tracking/index.md) for details.
-- [ ] After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) to enable the feature flag and start the experiment. For visibility, please run the command in the `#s_growth` channel:
+- Track necessary events. See the [event tracking guide](../event_tracking/index.md) for details.
+- After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) to enable the feature flag and start the experiment. For visibility, please run the command in the `#s_growth` channel:
 
   ```
   /chatops run feature set --project=gitlab-org/gitlab experimental_sign_up_flow true

doc/development/internal_api.md

@@ -287,8 +287,6 @@ Example response:
 }
 ```
 
-## Notify Post Receive [UNUSED] ?
-
 ## PostReceive
 
 Called from Gitaly after a receiving a push. This triggers the
@@ -300,7 +298,7 @@ the user.
 |:----------|:-------|:---------|:------------|
 | `identifier` | string | yes | `user-[id]` or `key-[id]` Identifying the user performing the push |
 | `gl_repository` | string | yes | identifier of the repository being pushed to |
-| `push_options` | [string] | no | array of push options |
+| `push_options` | string array | no | array of push options |
 | `changes` | string | no | refs to be updated in the push in the format `oldrev newrev refname\n`. |
 
 ```

doc/policy/maintenance.md

@@ -50,7 +50,7 @@ review process a new change goes through.
 
 Including new features in patch releases is not possible as that would break [Semantic Versioning](https://semver.org/).
 Breaking [Semantic Versioning](https://semver.org/) has the following consequences for users that
-have to adhere to various internal requirements (e.g. org. compliance, verifying new features and similar):
+have to adhere to various internal requirements (for example, org. compliance, verifying new features, and similar):
 
 1. Inability to quickly upgrade to leverage bug fixes included in patch versions.
 1. Inability to quickly upgrade to leverage security fixes included in patch versions.
@@ -58,9 +58,12 @@ have to adhere to various internal requirements (e.g. org. compliance, verifying
 
 In cases where a strategic user has a requirement to test a feature before it is
 officially released, we can offer to create a Release Candidate (RC) version that will
-include the specific feature. This should be needed only in extreme cases, and can be requested for consideration by raising an issue in [release/tasks] issue tracker.
-It is important to note that the Release Candidate will also contain other
-features and changes as it is not possible to easily isolate a specific feature (similar reasons as noted above). The Release Candidate will be no different than any code that is deployed to GitLab.com or is publicly accessible.
+include the specific feature. This should be needed only in extreme cases, and can be requested for
+consideration by raising an issue in the [release/tasks](https://gitlab.com/gitlab-org/release/tasks/issues/new?issuable_template=Backporting-request) issue tracker.
+It is important to note that the Release Candidate will also contain other features and changes as
+it is not possible to easily isolate a specific feature (similar reasons as noted above). The
+Release Candidate will be no different than any code that is deployed to GitLab.com or is publicly
+accessible.
 
 ### Backporting to older releases
 
@@ -68,11 +71,16 @@ Backporting to more than one stable release is reserved for [security releases](
 In some cases however, we may need to backport *a bug fix* to more than one stable
 release, depending on the severity of the bug.
 
-Decision on whether backporting a change will be performed is done at the discretion of the [current release managers][release-managers], similar to what is described in the [managing bugs] process, based on *all* of the following:
+The decision on whether backporting a change will be performed is done at the discretion of the
+[current release managers](https://about.gitlab.com/community/release-managers/), similar to what is
+described in the [managing bugs](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#managing-bugs) process,
+based on *all* of the following:
 
-1. Estimated [severity][severity-labels] of the bug: Highest possible impact to users based on the current definition of severity.
+1. Estimated [severity](../development/contributing/issue_workflow.md#severity-labels) of the bug:
+   Highest possible impact to users based on the current definition of severity.
 
-1. Estimated [priority][priority-definition] of the bug: Immediate impact on all impacted users based on the above estimated severity.
+1. Estimated [priority](../development/contributing/issue_workflow.md#priority-labels) of the bug:
+   Immediate impact on all impacted users based on the above estimated severity.
 
 1. Potentially incurring data loss and/or security breach.
 
@@ -83,7 +91,8 @@ the current stable stable release, and two previous monthly releases.
 For instance, if we release `11.2.1` with a fix for a severe bug introduced in
 `11.0.0`, we could backport the fix to a new `11.0.x`, and `11.1.x` patch release.
 
-To request backporting to more than one stable release for consideration, raise an issue in [release/tasks] issue tracker.
+To request backporting to more than one stable release for consideration, raise an issue in the
+[release/tasks](https://gitlab.com/gitlab-org/release/tasks/issues/new?issuable_template=Backporting-request) issue tracker.
 
 ### Security releases
 
@@ -146,9 +155,3 @@ Please see the table below for some examples:
 More information about the release procedures can be found in our
 [release documentation](https://gitlab.com/gitlab-org/release/docs). You may also want to read our
 [Responsible Disclosure Policy](https://about.gitlab.com/security/disclosure/).
-
-[release-managers]: https://about.gitlab.com/community/release-managers/
-[priority-definition]: ../development/contributing/issue_workflow.md#priority-labels
-[severity-labels]: ../development/contributing/issue_workflow.html#severity-labels
-[managing bugs]: https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#managing-bugs
-[release/tasks]: https://gitlab.com/gitlab-org/release/tasks/issues/new?issuable_template=Backporting-request