Convert reference links to standard links

As part of the work to enable another linting rule, convert
reference style links to standard style links.

doc/development/changelog.md

@@ -5,9 +5,9 @@ file, as well as information and history about our changelog process.
 
 ## Overview
 
-Each bullet point, or **entry**, in our [`CHANGELOG.md`][changelog.md] file is
-generated from a single data file in the [`changelogs/unreleased/`][unreleased]
-(or corresponding EE) folder. The file is expected to be a [YAML] file in the
+Each bullet point, or **entry**, in our [`CHANGELOG.md`](https://gitlab.com/gitlab-org/gitlab/blob/master/CHANGELOG.md) file is
+generated from a single data file in the [`changelogs/unreleased/`](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/changelogs/)
+(or corresponding EE) folder. The file is expected to be a [YAML](https://en.wikipedia.org/wiki/YAML) file in the
 following format:
 
 ```yaml
@@ -27,15 +27,12 @@ valid options are: added, fixed, changed, deprecated, removed, security, perform
 Community contributors and core team members are encouraged to add their name to
 the `author` field. GitLab team members **should not**.
 
-[changelog.md]: https://gitlab.com/gitlab-org/gitlab/blob/master/CHANGELOG.md
-[unreleased]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/changelogs/
-[YAML]: https://en.wikipedia.org/wiki/YAML
-
 ## What warrants a changelog entry?
 
 - Any change that introduces a database migration, whether it's regular, post,
   or data migration, **must** have a changelog entry.
-- [Security fixes] **must** have a changelog entry, without `merge_request` value
+- [Security fixes](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md)
+  **must** have a changelog entry, without `merge_request` value
   and with `type` set to `security`.
 - Any user-facing change **should** have a changelog entry. Example: "GitLab now
   uses system fonts for all text."
@@ -269,13 +266,14 @@ as the other was merged. When we had dozens of merge requests fighting for the
 same changelog entry location, this quickly became a major source of merge
 conflicts and delays in development.
 
-This led us to a [boring solution] of "add your entry in a random location in
+This led us to a [boring solution](https://about.gitlab.com/handbook/values/#boring-solutions) of "add your entry in a random location in
 the list." This actually worked pretty well as we got further along in each
 monthly release cycle, but at the start of a new cycle, when a new version
 section was added and there were fewer places to "randomly" add an entry, the
 conflicts became a problem again until we had a sufficient number of entries.
 
-On top of all this, it created an entirely different headache for [release managers]
+On top of all this, it created an entirely different headache for
+[release managers](https://gitlab.com/gitlab-org/release/docs/blob/master/quickstart/release-manager.md)
 when they cherry-picked a commit into a stable branch for a patch release. If
 the commit included an entry in the `CHANGELOG`, it would include the entire
 changelog for the latest version in `master`, so the release manager would have
@@ -283,16 +281,11 @@ to manually remove the later entries. They often would have had to do this
 multiple times per patch release. This was compounded when we had to release
 multiple patches at once due to a security issue.
 
-We needed to automate all of this manual work. So we [started brainstorming].
+We needed to automate all of this manual work. So we
+[started brainstorming](https://gitlab.com/gitlab-org/gitlab-foss/issues/17826).
 After much discussion we settled on the current solution of one file per entry,
 and then compiling the entries into the overall `CHANGELOG.md` file during the
-[release process].
-
-[boring solution]: https://about.gitlab.com/handbook/values/#boring-solutions
-[release managers]: https://gitlab.com/gitlab-org/release/docs/blob/master/quickstart/release-manager.md
-[started brainstorming]: https://gitlab.com/gitlab-org/gitlab-foss/issues/17826
-[release process]: https://gitlab.com/gitlab-org/release-tools
-[Security fixes]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md
+[release process](https://gitlab.com/gitlab-org/release-tools).
 
 ---
 

doc/development/code_review.md

@@ -472,15 +472,11 @@ A good example of collaboration on an MR touching multiple parts of the codebase
 
 ### Credits
 
-Largely based on the [thoughtbot code review guide].
-
-[thoughtbot code review guide]: https://github.com/thoughtbot/guides/tree/master/code-review
+Largely based on the [thoughtbot code review guide](https://github.com/thoughtbot/guides/tree/master/code-review).
 
 ---
 
 [Return to Development documentation](README.md)
 
-[projects]: https://about.gitlab.com/handbook/engineering/projects/
-[build handbook]: https://about.gitlab.com/handbook/build/handbook/build#how-to-work-with-build
 [^1]: Please note that specs other than JavaScript specs are considered backend code.
 [^2]: We encourage you to seek guidance from a database maintainer if your merge request is potentially introducing expensive queries. It is most efficient to comment on the line of code in question with the SQL queries so they can give their advice.

doc/development/contributing/issue_workflow.md

@@ -402,7 +402,8 @@ below will make it easy to manage this, without unnecessary overhead.
 
 Every monthly release has a corresponding issue on the CE issue tracker to keep
 track of functionality broken by that release and any fixes that need to be
-included in a patch release (see [8.3 Regressions] as an example).
+included in a patch release (see
+[8.3 Regressions](https://gitlab.com/gitlab-org/gitlab-foss/issues/4127) as an example).
 
 As outlined in the issue description, the intended workflow is to post one note
 with a reference to an issue describing the regression, and then to update that
@@ -412,11 +413,9 @@ If you're a contributor who doesn't have the required permissions to update
 other users' notes, please post a new note with a reference to both the issue
 and the merge request.
 
-The release manager will [update the notes] in the regression issue as fixes are
-addressed.
-
-[8.3 Regressions]: https://gitlab.com/gitlab-org/gitlab-foss/issues/4127
-[update the notes]: https://gitlab.com/gitlab-org/release-tools/blob/master/doc/pro-tips.md#update-the-regression-issue
+The release manager will
+[update the notes](https://gitlab.com/gitlab-org/release-tools/blob/master/doc/pro-tips.md#update-the-regression-issue)
+in the regression issue as fixes are addressed.
 
 ## Technical and UX debt
 

doc/development/documentation/styleguide.md

@@ -1349,11 +1349,9 @@ Replace `reconfigure` with `restart` where appropriate.
 In [step 2 of the installation guide](../../install/installation.md#2-ruby),
 we install Ruby from source. Whenever there is a new version that needs to
 be updated, remember to change it throughout the codeblock and also replace
-the sha256sum (it can be found in the [downloads page][ruby-dl] of the Ruby
+the sha256sum (it can be found in the [downloads page](https://www.ruby-lang.org/en/downloads/) of the Ruby
 website).
 
-[ruby-dl]: https://www.ruby-lang.org/en/downloads/ "Ruby download website"
-
 ### Configuration documentation for source and Omnibus installations
 
 GitLab currently officially supports two installation methods: installations
@@ -1380,7 +1378,7 @@ the style below as a guide:
    external_url "https://gitlab.example.com"
    ```
 
-1. Save the file and [reconfigure] GitLab for the changes to take effect.
+1. Save the file and [reconfigure](path/to/administration/restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
 
 ---
 
@@ -1393,10 +1391,7 @@ the style below as a guide:
      host: "gitlab.example.com"
    ```
 
-1. Save the file and [restart] GitLab for the changes to take effect.
-
-[reconfigure]: path/to/administration/restart_gitlab.md#omnibus-gitlab-reconfigure
-[restart]: path/to/administration/restart_gitlab.md#installations-from-source
+1. Save the file and [restart](path/to/administration/restart_gitlab.md#installations-from-source) GitLab for the changes to take effect.
 ````
 
 In this case:

doc/development/ee_features.md

@@ -9,7 +9,8 @@
 
 ## Act as CE when unlicensed
 
-Since the implementation of [GitLab CE features to work with unlicensed EE instance][ee-as-ce]
+Since the implementation of
+[GitLab CE features to work with unlicensed EE instance](https://gitlab.com/gitlab-org/gitlab/issues/2500)
 GitLab Enterprise Edition should work like GitLab Community Edition
 when no license is active. So EE features always should be guarded by
 `project.feature_available?` or `group.feature_available?` (or
@@ -24,8 +25,6 @@ setting the [`FOSS_ONLY` environment variable](https://gitlab.com/gitlab-org/git
 to something that evaluates as `true`. The same works for running tests
 (for example `FOSS_ONLY=1 yarn jest`).
 
-[ee-as-ce]: https://gitlab.com/gitlab-org/gitlab/issues/2500
-
 ## Separation of EE code
 
 All EE code should be put inside the `ee/` top-level directory. The
@@ -53,11 +52,9 @@ is applied not only to models. Here's a list of other examples:
 - `ee/app/views/foo/_bar.html.haml`
 
 This works because for every path that is present in CE's eager-load/auto-load
-paths, we add the same `ee/`-prepended path in [`config/application.rb`].
+paths, we add the same `ee/`-prepended path in [`config/application.rb`](https://gitlab.com/gitlab-org/gitlab/blob/925d3d4ebc7a2c72964ce97623ae41b8af12538d/config/application.rb#L42-52).
 This also applies to views.
 
-[`config/application.rb`]: https://gitlab.com/gitlab-org/gitlab/blob/925d3d4ebc7a2c72964ce97623ae41b8af12538d/config/application.rb#L42-52
-
 ### EE features based on CE features
 
 For features that build on existing CE features, write a module in the `EE`

doc/development/file_storage.md

 # File Storage in GitLab
 
-We use the [CarrierWave] gem to handle file upload, store and retrieval.
+We use the [CarrierWave](https://github.com/carrierwaveuploader/carrierwave) gem to handle file upload, store and retrieval.
 
 File uploads should be accelerated by workhorse, for details please refer to [uploads development documentation](uploads.md).
 
@@ -46,14 +46,14 @@ they are still not 100% standardized. You can see them below:
 CI Artifacts and LFS Objects behave differently in CE and EE. In CE they inherit the `GitlabUploader`
 while in EE they inherit the `ObjectStorage` and store files in and S3 API compatible object store.
 
-In the case of Issues/MR/Notes Markdown attachments, there is a different approach using the [Hashed Storage] layout,
+In the case of Issues/MR/Notes Markdown attachments, there is a different approach using the [Hashed Storage](../administration/repository_storage_types.md) layout,
 instead of basing the path into a mutable variable `:project_path_with_namespace`, it's possible to use the
 hash of the project ID instead, if project migrates to the new approach (introduced in 10.2).
 
-> Note: We provide an [all-in-one Rake task] to migrate all uploads to object
+> Note: We provide an [all-in-one Rake task](../administration/raketasks/uploads/migrate.md) to migrate all uploads to object
 > storage in one go. If a new Uploader class or model type is introduced, make
-> sure you add a Rake task invocation corresponding to it to the [category
-> list].
+> sure you add a Rake task invocation corresponding to it to the
+> [category list](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/tasks/gitlab/uploads/migrate.rake).
 
 ### Path segments
 
@@ -144,8 +144,3 @@ class Thing < ActiveRecord::Base
   ...
 end
 ```
-
-[CarrierWave]: https://github.com/carrierwaveuploader/carrierwave
-[Hashed Storage]: ../administration/repository_storage_types.md
-[all-in-one rake task]: ../administration/raketasks/uploads/migrate.md
-[category list]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/tasks/gitlab/uploads/migrate.rake

doc/development/interacting_components.md

@@ -9,7 +9,7 @@ when making _backend_ changes that might involve multiple features or [component
 
 ## Uploads
 
-GitLab supports uploads to [object storage]. That means every feature and
+GitLab supports uploads to [object storage](https://docs.gitlab.com/charts/advanced/external-object-storage/). That means every feature and
 change that affects uploads should also be tested against [object storage],
 which is _not_ enabled by default in [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit).
 
@@ -25,5 +25,3 @@ See also [File Storage in GitLab](file_storage.md).
 GitLab supports a great amount of features for [merge requests](../user/project/merge_requests/index.md). One
 of them is the ability to create merge requests from and to [forks](../gitlab-basics/fork-project.md),
 which should also be highly considered and tested upon development phase.
-
-[object storage]: https://docs.gitlab.com/charts/advanced/external-object-storage/

doc/development/performance.md

@@ -8,7 +8,7 @@ consistent performance of GitLab.
 The process of solving performance problems is roughly as follows:
 
 1. Make sure there's an issue open somewhere (for example, on the GitLab CE issue
-   tracker), and create one if there is not. See [#15607][#15607] for an example.
+   tracker), and create one if there is not. See [#15607](https://gitlab.com/gitlab-org/gitlab-foss/issues/15607) for an example.
 1. Measure the performance of the code in a production environment such as
    GitLab.com (see the [Tooling](#tooling) section below). Performance should be
    measured over a period of _at least_ 24 hours.
@@ -495,7 +495,7 @@ just memory but also unnecessary time spent in CPU and I/O for processing lines
 
 ## Anti-Patterns
 
-This is a collection of [anti-patterns][anti-pattern] that should be avoided
+This is a collection of [anti-patterns](https://en.wikipedia.org/wiki/Anti-pattern) that should be avoided
 unless these changes have a measurable, significant, and positive impact on
 production environments.
 
@@ -539,6 +539,3 @@ Assuming you are working with ActiveRecord models, you might also find these lin
 
 You may find some useful examples in this snippet:
 <https://gitlab.com/gitlab-org/gitlab-foss/snippets/33946>
-
-[#15607]: https://gitlab.com/gitlab-org/gitlab-foss/issues/15607
-[anti-pattern]: https://en.wikipedia.org/wiki/Anti-pattern