Update capitalization and backticks in /doc/dev

Update product name capitalization and implement
proper backtick use in /doc/development

doc/development/architecture.md

@@ -12,7 +12,7 @@ Both EE and CE require some add-on components called GitLab Shell and Gitaly. Th
 
 ## Components
 
-A typical install of GitLab will be on GNU/Linux. It uses Nginx or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and a [GitLab API](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/doc/api) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses redis as a non-persistent database backend for job information, meta data, and incoming jobs.
+A typical install of GitLab will be on GNU/Linux. It uses NGINX or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and the [GitLab API](../api/README.md) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses Redis as a non-persistent database backend for job information, meta data, and incoming jobs.
 
 We also support deploying GitLab on Kubernetes using our [GitLab Helm chart](https://docs.gitlab.com/charts/).
 
@@ -20,7 +20,7 @@ The GitLab web app uses PostgreSQL for persistent database information (e.g. use
 
 When serving repositories over HTTP/HTTPS GitLab utilizes the GitLab API to resolve authorization and access as well as serving Git objects.
 
-The add-on component GitLab Shell serves repositories over SSH. It manages the SSH keys within `/home/git/.ssh/authorized_keys` which should not be manually edited. GitLab Shell accesses the bare repositories through Gitaly to serve Git objects and communicates with redis to submit jobs to Sidekiq for GitLab to process. GitLab Shell queries the GitLab API to determine authorization and access.
+The add-on component GitLab Shell serves repositories over SSH. It manages the SSH keys within `/home/git/.ssh/authorized_keys` which should not be manually edited. GitLab Shell accesses the bare repositories through Gitaly to serve Git objects and communicates with Redis to submit jobs to Sidekiq for GitLab to process. GitLab Shell queries the GitLab API to determine authorization and access.
 
 Gitaly executes Git operations from GitLab Shell and the GitLab web app, and provides an API to the GitLab web app to get attributes from Git (e.g. title, branches, tags, other meta data), and to get blobs (e.g. diffs, commits, files).
 
@@ -224,7 +224,7 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag
 - Configuration: [Omnibus][geo-omnibus], [Charts][geo-charts], [GDK][geo-gdk]
 - Layer: Core Service (Processor)
 
-#### Gitlab Exporter
+#### GitLab Exporter
 
 - [Project page](https://gitlab.com/gitlab-org/gitlab-exporter)
 - Configuration: [Omnibus][gitlab-exporter-omnibus], [Charts][gitlab-exporter-charts]
@@ -258,7 +258,7 @@ GitLab CI is the open-source continuous integration service included with GitLab
 - Configuration: [Omnibus][shell-omnibus], [Charts][shell-charts], [Source][shell-source], [GDK][gitlab-yml]
 - Layer: Core Service (Processor)
 
-[GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell) is a program designed at GitLab to handle ssh-based `git` sessions, and modifies the list of authorized keys. GitLab Shell is not a Unix shell nor a replacement for Bash or Zsh.
+[GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell) is a program designed at GitLab to handle SSH-based `git` sessions, and modifies the list of authorized keys. GitLab Shell is not a Unix shell nor a replacement for Bash or Zsh.
 
 #### GitLab Workhorse
 
@@ -317,7 +317,7 @@ MinIO is an object storage server released under Apache License v2.0. It is comp
 - Layer: Core Service (Processor)
 - Process: `nginx`
 
-Nginx as an ingress port for all HTTP requests and routes them to the appropriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver.
+NGINX has an Ingress port for all HTTP requests and routes them to the appropriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver.
 
 #### Node Exporter
 
@@ -344,7 +344,7 @@ Lightweight connection pooler for PostgreSQL.
 
 Prometheus exporter for PgBouncer. Exports metrics at 9127/metrics.
 
-#### Postgresql
+#### PostgreSQL
 
 - [Project page](https://github.com/postgres/postgres/blob/master/README)
 - Configuration: [Omnibus][postgres-omnibus], [Charts][postgres-charts], [Source][postgres-source]
@@ -400,7 +400,7 @@ Redis is packaged to provide a place to store:
 - Layer: Core Service (Processor)
 
 The registry is what users use to store their own Docker images. The bundled
-registry uses nginx as a load balancer and GitLab as an authentication manager.
+registry uses NGINX as a load balancer and GitLab as an authentication manager.
 Whenever a client requests to pull or push an image from the registry, it will
 return a `401` response along with a header detailing where to get an
 authentication token, in this case the GitLab instance. The client will then
@@ -424,7 +424,7 @@ Sentry fundamentally is a service that helps you monitor and fix crashes in real
 - Layer: Core Service (Processor)
 - Process: `sidekiq`
 
-Sidekiq is a Ruby background job processor that pulls jobs from the redis queue and processes them. Background jobs allow GitLab to provide a faster request/response cycle by moving work into the background.
+Sidekiq is a Ruby background job processor that pulls jobs from the Redis queue and processes them. Background jobs allow GitLab to provide a faster request/response cycle by moving work into the background.
 
 #### Unicorn
 
@@ -470,9 +470,9 @@ It's important to understand the distinction as some processes are used in both
 
 When making a request to an HTTP Endpoint (think `/users/sign_in`) the request will take the following path through the GitLab Service:
 
-- nginx - Acts as our first line reverse proxy.
+- NGINX - Acts as our first line reverse proxy.
 - GitLab Workhorse - This determines if it needs to go to the Rails application or somewhere else to reduce load on Unicorn.
-- unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn.
+- Unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn.
 - Postgres/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data.
 
 ### GitLab Git Request Cycle
@@ -508,7 +508,7 @@ ps aux | grep '^git'
 ```
 
 GitLab has several components to operate. It requires a persistent database
-(PostgreSQL) and redis database, and uses Apache httpd or Nginx to proxypass
+(PostgreSQL) and Redis database, and uses Apache httpd or NGINX to proxypass
 Unicorn. All these components should run as different system users to GitLab
 (e.g., `postgres`, `redis` and `www-data`, instead of `git`).
 
@@ -580,7 +580,7 @@ SSH:
 - `/var/log/auth.log` auth log (on Ubuntu).
 - `/var/log/secure` auth log (on RHEL).
 
-nginx:
+NGINX:
 
 - `/var/log/nginx/` contains error and access logs.
 

doc/development/changelog.md

@@ -79,7 +79,7 @@ changes.
 
 - **Bad:** Strip out `nil`s in the Array of Commit objects returned from
   `find_commits_by_message_with_elastic`
-- **Good:** Fix 500 errors caused by elasticsearch results referencing
+- **Good:** Fix 500 errors caused by Elasticsearch results referencing
   garbage-collected commits
 
 The first example focuses on _how_ we fixed something, not on _what_ it fixes.

doc/development/database_debugging.md

@@ -3,7 +3,7 @@
 This section is to help give some copy-pasta you can use as a reference when you
 run into some head-banging database problems.
 
-An easy first step is to search for your error in Slack or google "GitLab (my error)".
+An easy first step is to search for your error in Slack, or search for `GitLab <my error>` with Google.
 
 ---
 

doc/development/documentation/improvement-workflow.md

@@ -20,7 +20,7 @@ to accomplish their work with GitLab.
 
 ## How to update the docs
 
-1. Click "Edit this Page" at the bottom of any page on docs.gitlab.com, or navigate to
+1. Click "Edit this Page" at the bottom of any page on <https://docs.gitlab.com>, or navigate to
    one of the repositories and doc paths listed on the [GitLab Documentation guidelines](index.md) page.
    Work in a fork if you do not have developer access to the GitLab project.
 1. Follow the described standards and processes listed on that Guidelines page,

doc/development/documentation/index.md

@@ -8,19 +8,18 @@ GitLab's documentation is [intended as the single source of truth (SSOT)](https:
 
 In addition to this page, the following resources can help you craft and contribute documentation:
 
-- [Style Guide](styleguide.md) - What belongs in the docs, language guidelines, and more.
+- [Style Guide](styleguide.md) - What belongs in the docs, language guidelines, Markdown standards to follow, and more.
 - [Structure and template](structure.md) - Learn the typical parts of a doc page and how to write each one.
 - [Workflows](workflow.md) - A landing page for our key workflows:
   - [Documentation process for feature changes](feature-change-workflow.md) - Adding required documentation when developing a GitLab feature.
   - [Documentation improvement workflow](improvement-workflow.md) - New content not associated with a new feature.
-- [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/) - A reference for the markdown implementation used by GitLab's documentation site and about.gitlab.com.
-- [Site architecture](site_architecture/index.md) - How docs.gitlab.com is built.
+- [Markdown Guide](../../user/markdown.md) - A reference for all markdown syntax supported by GitLab.
+- [Site architecture](site_architecture/index.md) - How <http://docs.gitlab.com> is built.
 
 ## Source files and rendered web locations
 
-Documentation for GitLab, GitLab Runner, and Omnibus is published to [docs.gitlab.com](https://docs.gitlab.com). Documentation for GitLab is also published within the application at `/help` on the domain of the GitLab instance.
-
-At `/help`, only help for your current edition and version is included. Help for other versions is available at docs.gitlab.com.
+Documentation for GitLab, GitLab Runner, Omnibus GitLab and Charts are published to <https://docs.gitlab.com>. Documentation for GitLab is also published within the application at `/help` on the domain of the GitLab instance.
+At `/help`, only help for your current edition and version is included. Help for other versions is available at <https://docs.gitlab.com/archives/>.
 
 The source of the documentation exists within the codebase of each GitLab application in the following repository locations:
 
@@ -29,6 +28,7 @@ The source of the documentation exists within the codebase of each GitLab applic
 | [GitLab](https://gitlab.com/gitlab-org/gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) |
 | [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/) | [`/docs`](https://gitlab.com/gitlab-org/gitlab-runner/tree/master/docs) |
 | [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) |
+| [Charts](https://gitlab.com/gitlab-org/charts/gitlab) | [`/doc`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/doc) |
 
 Documentation issues and merge requests are part of their respective repositories and all have the label `Documentation`.
 
@@ -55,8 +55,8 @@ See the [Structure](styleguide.md#structure) section of the [Documentation Style
 
 Changing a document's location requires specific steps to ensure that
 users can seamlessly access the new doc page, whether they are accessing content
-on a GitLab instance domain at `/help` or at docs.gitlab.com. Be sure to ping a
-GitLab technical writer if you have any questions during the process (such as
+on a GitLab instance domain at `/help` or at <https://docs.gitlab.com>. Be sure to assign a
+technical writer if you have any questions during the process (such as
 whether the move is necessary), and ensure that a technical writer reviews this
 change prior to merging.
 
@@ -132,7 +132,7 @@ land on the doc via `/help`.
 If the documentation page being relocated already has Disqus comments,
 we need to preserve the Disqus thread.
 
-Disqus uses an identifier per page, and for docs.gitlab.com, the page identifier
+Disqus uses an identifier per page, and for <https://docs.gitlab.com>, the page identifier
 is configured to be the page URL. Therefore, when we change the document location,
 we need to preserve the old URL as the same Disqus identifier.
 
@@ -181,9 +181,9 @@ Every GitLab instance includes the documentation, which is available at `/help`
 (`https://gitlab.example.com/help`). For example, <https://gitlab.com/help>.
 
 There are [plans](https://gitlab.com/groups/gitlab-org/-/epics/693) to end this
-practice and instead link out from the GitLab application to docs.gitlab.com URLs.
+practice and instead link out from the GitLab application to <https://docs.gitlab.com> URLs.
 
-The documentation available online on docs.gitlab.com is continuously
+The documentation available online on <https://docs.gitlab.com> is continuously
 deployed every hour from the `master` branch of GitLab, Omnibus, and Runner. Therefore,
 once a merge request gets merged, it will be available online on the same day.
 However, they will be shipped (and available on `/help`) within the milestone assigned
@@ -195,7 +195,7 @@ available online on 2018-09-15, but, as the feature freeze date has passed, if
 the MR does not have a "pick into 11.3" label, the milestone has to be changed
 to 11.4 and it will be shipped with all GitLab packages only on 2018-10-22,
 with GitLab 11.4. Meaning, it will only be available under `/help` from GitLab
-11.4 onwards, but available on docs.gitlab.com on the same day it was merged.
+11.4 onwards, but available on <https://docs.gitlab.com/archives/> on the same day it was merged.
 
 ### Linking to `/help`
 
@@ -271,7 +271,7 @@ For example, [GitLab.com's `/help`](https://gitlab.com/help).
 ## Docs site architecture
 
 See the [Docs site architecture](site_architecture/index.md) page to learn
-how we build and deploy the site at [docs.gitlab.com](https://docs.gitlab.com) and
+how we build and deploy the site at <https://docs.gitlab.com> and
 to review all the assets and libraries in use.
 
 ### Global navigation
@@ -301,7 +301,7 @@ You will need to push a branch to those repositories, it doesn't work for forks.
 
 The `review-docs-deploy*` job will:
 
-1. Create a new branch in the [gitlab-docs](https://gitlab.com/gitlab-org/gitlab-docs)
+1. Create a new branch in the [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs)
    project named after the scheme: `$DOCS_GITLAB_REPO_SUFFIX-$CI_ENVIRONMENT_SLUG`,
    where `DOCS_GITLAB_REPO_SUFFIX` is the suffix for each product, e.g, `ce` for
    CE, etc.

doc/development/documentation/styleguide.md

@@ -564,7 +564,7 @@ Inside the document:
 
 ### Remove image shadow
 
-All images displayed on docs.gitlab.com have a box shadow by default.
+All images displayed on the [GitLab Docs site](https://docs.gitlab.com) have a box shadow by default.
 To remove the box shadow, use the image class `.image-noshadow` applied
 directly to an HTML `img` tag:
 
@@ -598,7 +598,7 @@ You can link any up-to-date video that is useful to the GitLab user.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/472) in GitLab 12.1.
 
-GitLab docs (docs.gitlab.com) support embedded videos.
+The [GitLab docs site](https://docs.gitlab.com) supports embedded videos.
 
 You can only embed videos from
 [GitLab's official YouTube account](https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg).
@@ -634,7 +634,7 @@ leave a blank line here
 leave a blank line here
 ```
 
-This is how it renders on docs.gitlab.com:
+This is how it renders on the GitLab Docs site:
 
 <div class="video-fallback">
   See the video: <a href="https://www.youtube.com/watch?v=enMumwvLAug">What is GitLab</a>.
@@ -693,6 +693,10 @@ use the following markup for highlighting.
 _Note that the alert boxes only work for one paragraph only. Multiple paragraphs,
 lists, headers, etc will not render correctly. For multiple lines, use blockquotes instead._
 
+Alert boxes only render properly on the GitLab Docs site (<http://docs.gitlab.com>).
+Within GitLab itself, they will appear as plain markdown text (like the examples
+above the rendered versions, below).
+
 ### Note
 
 Notes catch the eye of most readers, and therefore should be used very sparingly.
@@ -717,7 +721,7 @@ NOTE: **Note:**
 This is something to note.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 NOTE: **Note:**
 This is something to note.
@@ -729,7 +733,7 @@ TIP: **Tip:**
 This is a tip.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 TIP: **Tip:**
 This is a tip.
@@ -741,7 +745,7 @@ CAUTION: **Caution:**
 This is something to be cautious about.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 CAUTION: **Caution:**
 This is something to be cautious about.
@@ -753,7 +757,7 @@ DANGER: **Danger:**
 This is a breaking change, a bug, or something very important to note.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 DANGER: **Danger:**
 This is a breaking change, a bug, or something very important to note.
@@ -766,7 +770,7 @@ For highlighting a text within a blue blockquote, use this format:
 > This is a blockquote.
 ```
 
-which renders in docs.gitlab.com to:
+which renders on the [GitLab Docs site](https://docs.gitlab.com) as:
 
 > This is a blockquote.
 
@@ -1154,7 +1158,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --form "title=
 ```
 
 The above example is run by and administrator and will add an SSH public key
-titled ssh-key to user's account which has an id of 25.
+titled `ssh-key` to user's account which has an id of 25.
 
 #### Escape special characters
 

doc/development/elasticsearch.md

 # Elasticsearch knowledge **(STARTER ONLY)**
 
-This area is to maintain a compendium of useful information when working with elasticsearch.
+This area is to maintain a compendium of useful information when working with Elasticsearch.
 
-Information on how to enable Elasticsearch and perform the initial indexing is kept in ../integration/elasticsearch.md#enabling-elasticsearch
+Information on how to enable Elasticsearch and perform the initial indexing is in
+the [Elasticsearch integration documentation](../integration/elasticsearch.md#enabling-elasticsearch)
 
 ## Deep Dive
 
@@ -61,7 +62,7 @@ Additionally, if you need large repos or multiple forks for testing, please cons
 
 The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb).
 
-All indexing after the initial one is done via `ElasticIndexerWorker` (sidekiq jobs).
+All indexing after the initial one is done via `ElasticIndexerWorker` (Sidekiq jobs).
 
 Search queries are generated by the concerns found in [ee/app/models/concerns/elastic](https://gitlab.com/gitlab-org/gitlab/tree/master/ee/app/models/concerns/elastic). These concerns are also in charge of access control, and have been a historic source of security bugs so please pay close attention to them!
 

doc/development/event_tracking/frontend.md

 # Frontend tracking guide
 
-GitLab provides `Tracking`, an interface that wraps the [Snowplow Javascript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilizing tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy).
+GitLab provides `Tracking`, an interface that wraps the [Snowplow JavaScript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilizing tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy).
 
 | field      | type   | default value              | description |
 |:-----------|:-------|:---------------------------|:------------|
@@ -26,7 +26,7 @@ Below is an example of `data-track-*` attributes assigned to a button:
 />
 ```
 
-Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw Javascript](#tracking-in-raw-javascript).
+Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw JavaScript](#tracking-in-raw-javascript).
 
 Below is a list of supported `data-track-*` attributes:
 
@@ -99,7 +99,7 @@ And if needed within the template, you can use the `track` method directly as we
 </template>
 ```
 
-## Tracking in raw Javascript
+## Tracking in raw JavaScript
 
 Custom event tracking and instrumentation can be added by directly calling the `Tracking.event` static function. The following example demonstrates tracking a click on a button by calling `Tracking.event` manually.
 

doc/development/fe_guide/components.md

@@ -8,7 +8,7 @@
 
 See also the [corresponding UX guide](https://design.gitlab.com/#/components/dropdowns).
 
-### How to style a bootstrap dropdown
+### How to style a Bootstrap dropdown
 
 1. Use the HTML structure provided by the [docs][bootstrap-dropdowns]
 1. Add a specific class to the top level `.dropdown` element

doc/development/fe_guide/development_process.md

@@ -80,7 +80,7 @@ With the purpose of being [respectful of others' time](https://about.gitlab.com/
 
 1. Before writing code, ensure your vision of the architecture is aligned with
    GitLab's architecture.
-1. Add a diagram to the issue and ask a frontend maintainer in the slack channel `#frontend_maintainers` about it.
+1. Add a diagram to the issue and ask a frontend maintainer in the Slack channel `#frontend_maintainers` about it.
 
    ![Diagram of Issue Boards Architecture](img/boards_diagram.png)
 

doc/development/fe_guide/icons.md

 # Icons and SVG Illustrations
 
-We manage our own Icon and Illustration library in the [gitlab-svgs][gitlab-svgs] repository.
+We manage our own Icon and Illustration library in the [`gitlab-svgs`][gitlab-svgs] repository.
 This repository is published on [npm][npm] and managed as a dependency via yarn.
 You can browse all available Icons and Illustrations [here][svg-preview].
 To upgrade to a new version run `yarn upgrade @gitlab/svgs`.

doc/development/fe_guide/performance.md

@@ -65,26 +65,27 @@ within the `pages` directory correspond to Rails controllers and actions. These
 auto-generated bundles will be automatically included on the corresponding
 pages.
 
-For example, if you were to visit [gitlab.com/gitlab-org/gitlab-foss/issues](https://gitlab.com/gitlab-org/gitlab-foss/issues),
+For example, if you were to visit <https://gitlab.com/gitlab-org/gitlab/issues>,
 you would be accessing the `app/controllers/projects/issues_controller.rb`
 controller with the `index` action. If a corresponding file exists at
 `pages/projects/issues/index/index.js`, it will be compiled into a webpack
 bundle and included on the page.
 
-> **Note:** Previously we had encouraged the use of
-> `content_for :page_specific_javascripts` within haml files, along with
-> manually generated webpack bundles. However under this new system you should
-> not ever need to manually add an entry point to the `webpack.config.js` file.
->
-> **Tip:**
-> If you are unsure what controller and action corresponds to a given page, you
-> can find this out by inspecting `document.body.dataset.page` within your
-> browser's developer console while on any page within gitlab.
+NOTE: **Note:**
+Previously we had encouraged the use of
+`content_for :page_specific_javascripts` within haml files, along with
+manually generated webpack bundles. However under this new system you should
+not ever need to manually add an entry point to the `webpack.config.js` file.
+
+TIP: **Tip:**
+If you are unsure what controller and action corresponds to a given page, you
+can find this out by inspecting `document.body.dataset.page` within your
+browser's developer console while on any page within GitLab.
 
 #### Important Considerations
 
 - **Keep Entry Points Lite:**
-  Page-specific javascript entry points should be as lite as possible.  These
+  Page-specific JavaScript entry points should be as lite as possible.  These
   files are exempt from unit tests, and should be used primarily for
   instantiation and dependency injection of classes and methods that live in
   modules outside of the entry point script.  Just import, read the DOM,

doc/development/fe_guide/security.md

@@ -63,7 +63,7 @@ External fonts, CSS, and JavaScript should never be used with the exception of
 Google Analytics and Piwik - and only when the instance has enabled it. Assets
 should always be hosted and served locally from the GitLab instance. Embedded
 resources via `iframes` should never be used except in certain circumstances
-such as with ReCaptcha, which cannot be used without an `iframe`.
+such as with reCAPTCHA, which cannot be used without an `iframe`.
 
 ## Avoiding inline scripts and styles
 

doc/development/fe_guide/style_guide_js.md

@@ -287,7 +287,7 @@ See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab/blob/master/.es
 
 #### CSS classes used for JavaScript
 
-1. If the class is being used in Javascript it needs to be prepend with `js-`
+1. If the class is being used in JavaScript it needs to be prepend with `js-`
 
    ```html
    // bad
@@ -693,7 +693,7 @@ Useful links:
    $('span').tooltip('_fixTitle');
    ```
 
-### The Javascript/Vue Accord
+### The JavaScript/Vue Accord
 
 The goal of this accord is to make sure we are all on the same page.
 

doc/development/feature_flags/controls.md

@@ -3,7 +3,7 @@
 In order to be able to turn on/off features behind feature flags in any of the
 GitLab Inc. provided environments such as staging and production, you need to
 have access to the chatops bot. Chatops bot is currently running on the ops instance,
-which is different from GitLab.com or dev.gitlab.org.
+which is different from <https://gitlab.com> or <https://dev.gitlab.org>.
 
 Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#requesting-access).
 
@@ -39,7 +39,7 @@ If you get an error "Whoops! This action is not allowed. This incident
 will be reported." that means your Slack account is not allowed to
 change feature flags or you do not [have access](#access-for-enabling-a-feature-flag-in-production).
 
-### Enabling feature for staging and dev.gitlab.org
+### Enabling feature for internal testing
 
 As a first step in a feature rollout, you should enable the feature on <https://staging.gitlab.com>
 and <https://dev.gitlab.org>.

doc/development/gitaly.md

@@ -15,9 +15,9 @@ In May 2019, Bob Van Landuyt hosted a [Deep Dive] on GitLab's [Gitaly project] a
 
 ## Beginner's guide
 
-Start by reading the gitaly repository's
+Start by reading the Gitaly repository's
 [Beginner's guide to Gitaly contributions](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/beginners_guide.md).
-It describes how to setup gitaly, the various components of gitaly and what they do, and how to run its test suites.
+It describes how to setup Gitaly, the various components of Gitaly and what they do, and how to run its test suites.
 
 ## Developing new Git features
 
@@ -41,14 +41,14 @@ disk access (e.g. Rugged, `git`, `rm -rf`) anywhere outside
 The process for adding new Gitaly features is:
 
 - exploration / prototyping
-- design and create a new Gitaly RPC [in gitaly-proto](https://gitlab.com/gitlab-org/gitaly-proto)
-- release a new version of gitaly-proto
+- design and create a new Gitaly RPC in [`gitaly-proto`](https://gitlab.com/gitlab-org/gitaly-proto)
+- release a new version of `gitaly-proto`
 - write implementation and tests for the RPC [in Gitaly](https://gitlab.com/gitlab-org/gitaly), in Go or Ruby
 - release a new version of Gitaly
 - write client code in GitLab CE/EE, GitLab Workhorse or GitLab Shell that calls the new Gitaly RPC
 
 These steps often overlap. It is possible to use an unreleased version
-of Gitaly and gitaly-proto during testing and development.
+of Gitaly and `gitaly-proto` during testing and development.
 
 - See the [Gitaly repo](https://gitlab.com/gitlab-org/gitaly/blob/master/CONTRIBUTING.md#development-and-testing-with-a-custom-gitaly-proto) for instructions on writing server side code with an unreleased protocol.
 - See [below](#running-tests-with-a-locally-modified-version-of-gitaly) for instructions on running GitLab CE tests with a modified version of Gitaly.
@@ -58,7 +58,7 @@ of Gitaly and gitaly-proto during testing and development.
 
 It is possible to implement and test RPC's in Gitaly using Ruby code,
 in
-[gitaly-ruby](https://gitlab.com/gitlab-org/gitaly/tree/master/ruby).
+[`gitaly-ruby`](https://gitlab.com/gitlab-org/gitaly/tree/master/ruby).
 This should make it easier to contribute for developers who are less
 comfortable writing Go code.
 
@@ -234,7 +234,7 @@ Here are the steps to gate a new feature in Gitaly behind a feature flag.
    }
    ```
 
-1. Create prometheus metrics:
+1. Create Prometheus metrics:
 
    ```go
    var findAllTagsRequests = prometheus.NewCounterVec(

doc/development/i18n/index.md

@@ -29,7 +29,7 @@ See [Externalization for GitLab](externalization.md).
 
 ### Translate strings
 
-The translation process is managed at [translate.gitlab.com](https://translate.gitlab.com)
+The translation process is managed at <https://translate.gitlab.com>
 using [Crowdin](https://crowdin.com/).
 You will need to create an account before you can submit translations.
 Once you are signed in, select the language you wish to contribute translations to.

doc/development/i18n/proofreader.md

@@ -57,7 +57,7 @@ are very appreciative of the work done by translators and proofreaders!
   - Paolo Falomo - [GitLab](https://gitlab.com/paolofalomo), [Crowdin](https://crowdin.com/profile/paolo.falomo)
 - Japanese
   - Hiroyuki Sato - [GitLab](https://gitlab.com/hiroponz), [Crowdin](https://crowdin.com/profile/hiroponz)
-  - Tomo Dote - [Gitlab](https://gitlab.com/fu7mu4), [Crowdin](https://crowdin.com/profile/fu7mu4)
+  - Tomo Dote - [GitLab](https://gitlab.com/fu7mu4), [Crowdin](https://crowdin.com/profile/fu7mu4)
 - Korean
   - Chang-Ho Cha - [GitLab](https://gitlab.com/changho-cha), [Crowdin](https://crowdin.com/profile/zzazang)
   - Ji Hun Oh - [GitLab](https://gitlab.com/Baw-Appie), [Crowdin](https://crowdin.com/profile/BawAppie)

doc/development/i18n/translation.md

@@ -8,7 +8,7 @@ The first step is to get familiar with Crowdin.
 
 ### Sign In
 
-To contribute translations at [translate.gitlab.com](https://translate.gitlab.com)
+To contribute translations at <https://translate.gitlab.com>
 you must create a Crowdin account.
 You may create a new account or use any of their supported sign in services.
 
@@ -54,7 +54,7 @@ For example in French `OpenedNDaysAgo|Opened` would be translated to
 Some technical terms should be treated like proper nouns and not be translated.
 
 Technical terms that should always be in English are noted in the glossary when
-using [translate.gitlab.com](https://translate.gitlab.com).
+using <https://translate.gitlab.com>.
 
 This helps maintain a logical connection and consistency between tools (e.g.
 `git` client) and GitLab.

doc/development/import_export.md

@@ -36,7 +36,7 @@ SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS = 3000000
 SIDEKIQ_MEMORY_KILLER_GRACE_TIME = 900
 ```
 
-An import status `started`, and the following sidekiq logs will signal a memory issue:
+An import status `started`, and the following Sidekiq logs will signal a memory issue:
 
 ```bash
 WARN: Work still in progress <struct with JID>

doc/development/interacting_components.md

@@ -14,7 +14,7 @@ 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).
 
 When working on a related feature, make sure to enable and test it
-against [Minio](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/object_storage.md).
+against [MinIO](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/object_storage.md).
 
 See also [File Storage in GitLab](file_storage.md).
 

doc/development/kubernetes.md

@@ -44,12 +44,11 @@ to the relevant internal client.
 
 All calls to the Kubernetes API must be in a background process. Do not
 perform Kubernetes API calls within a web request as this will block
-unicorn and can easily lead to a Denial Of Service (DoS) attack in GitLab as
+Unicorn and can easily lead to a Denial Of Service (DoS) attack in GitLab as
 the Kubernetes cluster response times are outside of our control.
 
 The easiest way to ensure your calls happen a background process is to
-delegate any such work to happen in a [sidekiq
-worker](sidekiq_style_guide.md).
+delegate any such work to happen in a [Sidekiq worker](sidekiq_style_guide.md).
 
 There are instances where you would like to make calls to Kubernetes and
 return the response and as such a background worker does not seem to be

doc/development/new_fe_guide/development/components.md

@@ -7,7 +7,7 @@ We have a lot of graphing libraries in our codebase to render graphs. In an effo
 We chose D3 as our library going forward because of the following features:
 
 - [Tree shaking webpack capabilities](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
-- [Compatible with vue.js as well as vanilla javascript](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
+- [Compatible with vue.js as well as vanilla JavaScript](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
 
 D3 is very popular across many projects outside of GitLab:
 

doc/development/new_fe_guide/development/performance.md

@@ -2,9 +2,9 @@
 
 ## Monitoring
 
-We have a performance dashboard available in one of our [grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
+We have a performance dashboard available in one of our [Grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
 
-These pages can be found inside a text file in the gitlab-build-images [repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [gitlab.txt](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
+These pages can be found inside a text file in the [`gitlab-build-images` repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [`gitlab.txt`](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
 Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
 
 There are 3 recommended high impact metrics to review on each page:

doc/development/sidekiq_style_guide.md

@@ -27,7 +27,7 @@ While different workers cannot share a queue, they can share a queue namespace.
 Defining a queue namespace for a worker makes it possible to start a Sidekiq
 process that automatically handles jobs for all workers in that namespace,
 without needing to explicitly list all their queue names. If, for example, all
-workers that are managed by sidekiq-cron use the `cronjob` queue namespace, we
+workers that are managed by `sidekiq-cron` use the `cronjob` queue namespace, we
 can spin up a Sidekiq process specifically for these kinds of scheduled jobs.
 If a new worker using the `cronjob` namespace is added later on, the Sidekiq
 process will automatically pick up jobs for that worker too (after having been

doc/development/testing_guide/best_practices.md

@@ -113,7 +113,7 @@ Finished in 34.51 seconds (files took 0.76702 seconds to load)
 1 example, 0 failures
 ```
 
-Note: `live_debug` only works on javascript enabled specs.
+Note: `live_debug` only works on JavaScript enabled specs.
 
 #### Run `:js` spec in a visible browser
 
@@ -158,7 +158,7 @@ really fast since:
 
 - Gems loading is skipped
 - Rails app boot is skipped
-- gitlab-shell and Gitaly setup are skipped
+- GitLab Shell and Gitaly setup are skipped
 - Test repositories setup are skipped
 
 `fast_spec_helper` also support autoloading classes that are located inside the
@@ -347,7 +347,7 @@ them unspecified, and look up the value after the row is created.
 
 #### Redis
 
-GitLab stores two main categories of data in Redis: cached items, and sidekiq
+GitLab stores two main categories of data in Redis: cached items, and Sidekiq
 jobs.
 
 In most specs, the Rails cache is actually an in-memory store. This is replaced
@@ -587,9 +587,9 @@ All fixtures should be placed under `spec/fixtures/`.
 
 ### Repositories
 
-Testing some functionality, e.g., merging a merge request, requires a git
+Testing some functionality, e.g., merging a merge request, requires a Git
 repository with a certain state to be present in the test environment. GitLab
-maintains the [gitlab-test](https://gitlab.com/gitlab-org/gitlab-test)
+maintains the [`gitlab-test`](https://gitlab.com/gitlab-org/gitlab-test)
 repository for certain common cases - you can ensure a copy of the repository is
 used with the `:repository` trait for project factories:
 

doc/development/testing_guide/end_to_end/page_objects.md

@@ -2,7 +2,7 @@
 
 In GitLab QA we are using a known pattern, called _Page Objects_.
 
-This means that we have built an abstraction for all GitLab pages that we use
+This means that we have built an abstraction for all pages in GitLab that we use
 to drive GitLab QA scenarios. Whenever we do something on a page, like filling
 in a form, or clicking a button, we do that only through a page object
 associated with this area of GitLab.

doc/development/testing_guide/flaky_tests.md

@@ -61,7 +61,7 @@ This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/m
   - [Capybara.reset_session! should be called before requests are blocked](https://gitlab.com/gitlab-org/gitlab-foss/issues/33779): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12224>
 - FFaker generates funky data that tests are not ready to handle (and tests should be predictable so that's bad!):
   - [Make `spec/mailers/notify_spec.rb` more robust](https://gitlab.com/gitlab-org/gitlab-foss/issues/20121): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10015>
-  - [Transient failure in spec/requests/api/commits_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9944>
+  - [Transient failure in `spec/requests/api/commits_spec.rb`](https://gitlab.com/gitlab-org/gitlab-foss/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9944>
   - [Replace FFaker factory data with sequences](https://gitlab.com/gitlab-org/gitlab-foss/issues/29643): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10184>
   - [Transient failure in spec/finders/issues_finder_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/30211#note_26707685): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10404>
 

doc/development/testing_guide/frontend_testing.md

@@ -482,7 +482,7 @@ As long as the fixtures don't change, `yarn test` is sufficient (and saves you s
 
 While developing locally, it may be helpful to keep Karma running so that you
 can get instant feedback on as you write tests and modify code. To do this
-you can start Karma with `yarn run karma-start`. It will compile the javascript
+you can start Karma with `yarn run karma-start`. It will compile the JavaScript
 assets and run a server at `http://localhost:9876/` where it will automatically
 run the tests on any browser which connects to it. You can enter that url on
 multiple browsers at once to have it run the tests on each in parallel.

doc/development/testing_guide/review_apps.md

@@ -142,7 +142,7 @@ their node under pressure.
 ### Log into my Review App
 
 The default username is `root` and its password can be found in the 1Password
-secure note named **gitlab-{ce,ee} Review App's root password**.
+secure note named `gitlab-{ce,ee} Review App's root password`.
 
 ### Enable a feature flag for my Review App
 
@@ -235,7 +235,7 @@ For the record, the debugging steps to find out this issue were:
 1. Switch kubectl context to review-apps-ce (we recommend using [kubectx](https://github.com/ahmetb/kubectx/))
 1. `kubectl get pods | grep dns`
 1. `kubectl describe pod <pod name>` & confirm exact error message
-1. Web search for exact error message, following rabbit hole to [a relevant kubernetes bug report](https://github.com/kubernetes/kubernetes/issues/57345)
+1. Web search for exact error message, following rabbit hole to [a relevant Kubernetes bug report](https://github.com/kubernetes/kubernetes/issues/57345)
 1. Access the node over SSH via the GCP console (**Computer Engine > VM
    instances** then click the "SSH" button for the node where the `dns-gitlab-review-app-external-dns` pod runs)
 1. In the node: `systemctl --version` => systemd 232

doc/development/uploads.md

@@ -82,7 +82,7 @@ To address this problem an HA object storage can be used and it's supported by [
 
 Scaling NFS is outside of our support scope, and NFS is not a part of cloud native installations.
 
-All features that require sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since sidekiq POD cannot reach into other pods, the operation will fail to read it.
+All features that require Sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since Sidekiq POD cannot reach into other pods, the operation will fail to read it.
 
 ## How to select the proper level of acceleration?
 
@@ -92,19 +92,19 @@ We can identify three major use-cases for an upload:
 
 1. **storage:** if we are uploading for storing a file (i.e. artifacts, packages, discussion attachments). In this case [object storage acceleration](#workhorse-object-storage-acceleration) is the proper level as it's the less resource-intensive operation. Additional information can be found on [File Storage in GitLab](file_storage.md).
 1. **in-controller/synchronous processing:** if we allow processing **small files** synchronously, using [disk acceleration](#workhorse-disk-acceleration) may speed up development.
-1. **sidekiq/asynchronous processing:** Async processing must implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
+1. **Sidekiq/asynchronous processing:** Async processing must implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
 
 For more details about currently broken feature see [epic &1802](https://gitlab.com/groups/gitlab-org/-/epics/1802).
 
 ### Handling repository uploads
 
-Some features involves git repository uploads without using a regular git client.
+Some features involves Git repository uploads without using a regular Git client.
 Some examples are uploading a repository file from the web interface and [design management](../user/project/issues/design_management.md).
 
-Those uploads requires the rails controller to act as a git client in lieu of the user.
+Those uploads requires the rails controller to act as a Git client in lieu of the user.
 Those operation falls into _in-controller/synchronous processing_ category, but we have no warranties on the file size.
 
-In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with sidekiq.
+In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with Sidekiq.
 
 ## Upload encodings
 
@@ -114,7 +114,7 @@ We have three kinds of file encoding in our uploads:
 
 1. <i class="fa fa-check-circle"></i> **multipart**: `multipart/form-data` is the most common, a file is encoded as a part of a multipart encoded request.
 1. <i class="fa fa-check-circle"></i> **body**: some APIs uploads files as the whole request body.
-1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This requires [gitlab-workhorse#226](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/226) to be implemented.
+1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This will require a change to GitLab Workhorse, which [is planned](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/226).
 
 ## Uploading technologies
 
@@ -212,7 +212,9 @@ In this setup an extra rails route needs to be implemented in order to handle au
 you can see an example of this in [`Projects::LfsStorageController`](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/app/controllers/projects/lfs_storage_controller.rb)
 and [its routes](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/config/routes/git_http.rb#L31-32).
 
-**note:** this will fallback to _Workhorse disk acceleration_ when object storage is not enabled in the gitlab instance. The answer to the `/authorize` call will only contain a file system path.
+NOTE: **Note:**
+This will fall back to _Workhorse disk acceleration_ when object storage is not enabled
+in the GitLab instance. The answer to the `/authorize` call will only contain a file system path.
 
 ```mermaid
 sequenceDiagram
@@ -267,4 +269,4 @@ sequenceDiagram
 
 This option affect the response to the `/authorize` call. When not enabled, the API response will not contain presigned URLs and workhorse will write the file the shared disk, on the path is provided by rails, acting like object storage was disabled.
 
-Once the request reachs rails, it will schedule an object storage upload as a sidekiq job.
+Once the request reachs rails, it will schedule an object storage upload as a Sidekiq job.