diff options
author | Evan Read <eread@gitlab.com> | 2018-11-27 07:31:47 +0300 |
---|---|---|
committer | Evan Read <eread@gitlab.com> | 2018-11-27 07:31:47 +0300 |
commit | 2ee8c40fc16d977a2aed07bdcbb9c4eecb08d80d (patch) | |
tree | a7f869cee88d0f344c239e781238c1fa72c3e646 /doc/development | |
parent | ae975b9f1e8eeefd0e3b75c90101c1d7aaffa312 (diff) | |
parent | e238882d0c18c75b41b71f05ce44f5717fc75b4d (diff) |
Merge branch '54230-eliminate-duplicated-words' into 'master'
Eliminate duplicated words (for docs)
See merge request gitlab-org/gitlab-ce!23183
Diffstat (limited to 'doc/development')
-rw-r--r-- | doc/development/architecture.md | 4 | ||||
-rw-r--r-- | doc/development/contributing/issue_workflow.md | 2 | ||||
-rw-r--r-- | doc/development/ee_features.md | 2 | ||||
-rw-r--r-- | doc/development/fe_guide/droplab/droplab.md | 2 | ||||
-rw-r--r-- | doc/development/testing_guide/best_practices.md | 8 |
5 files changed, 9 insertions, 9 deletions
diff --git a/doc/development/architecture.md b/doc/development/architecture.md index 01d99c46f89..931a7a8e6d5 100644 --- a/doc/development/architecture.md +++ b/doc/development/architecture.md @@ -42,7 +42,7 @@ run: unicorn: (pid 30960) 14204s; run: log: (pid 13809) 2432047s GitLab can be considered to have two layers from a process perspective: - **Monitoring**: Anything from this layer is not required to deliver GitLab the application, but will allow administrators more insight into their infrastructure and what the service as a whole is doing. -- **Core**: Any process that is vital for the delivery of GitLab as as platform. If any of these processes halt there will be a GitLab outage. For the Core layer, you can further divide into: +- **Core**: Any process that is vital for the delivery of GitLab as a platform. If any of these processes halt there will be a GitLab outage. For the Core layer, you can further divide into: - **Processors**: These processes are responsible for actually performing operations and presenting the service. - **Data**: These services store/expose structured data for the GitLab service. @@ -86,7 +86,7 @@ GitLab is comprised of a large number of services that all log. We started bundl - [Omnibus configuration options](https://docs.gitlab.com/omnibus/settings/nginx.html) - Layer: Core Service (Processor) -Nginx as as an ingress port for all HTTP requests and routes them to the approriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver. +Nginx as an ingress port for all HTTP requests and routes them to the approriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver. ### node-exporter diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md index 233dc83f95b..7c7da50a149 100644 --- a/doc/development/contributing/issue_workflow.md +++ b/doc/development/contributing/issue_workflow.md @@ -175,7 +175,7 @@ Severity levels can be applied further depending on the facet of the impact; e.g | ~S1 | >50% users affected (possible company extinction level event) | Significant impact on all of GitLab.com | | | ~S2 | Many users or multiple paid customers affected (but not apocalyptic)| Significant impact on large portions of GitLab.com | Degradation is guaranteed to occur in the near future | | ~S3 | A few users or a single paid customer affected | Limited impact on important portions of GitLab.com | Degradation is likely to occur in the near future | -| ~S4 | No paid users/customer affected, or expected to in the near future | Minor impact on on GitLab.com | Degradation _may_ occur but it's not likely | +| ~S4 | No paid users/customer affected, or expected to in the near future | Minor impact on GitLab.com | Degradation _may_ occur but it's not likely | ## Label for community contributors diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md index 9aea03139ee..a227e2f6640 100644 --- a/doc/development/ee_features.md +++ b/doc/development/ee_features.md @@ -419,7 +419,7 @@ view. For instance the approval code in the project's settings page. **Mitigations** Blocks of code that are EE-specific should be moved to partials. This -avoids conflicts with big chunks of HAML code that that are not fun to +avoids conflicts with big chunks of HAML code that are not fun to resolve when you add the indentation to the equation. EE-specific views should be placed in `ee/app/views/`, using extra diff --git a/doc/development/fe_guide/droplab/droplab.md b/doc/development/fe_guide/droplab/droplab.md index 112ff3419d9..ce96a9fc8ae 100644 --- a/doc/development/fe_guide/droplab/droplab.md +++ b/doc/development/fe_guide/droplab/droplab.md @@ -123,7 +123,7 @@ droplab.init().addData([{ ``` Alternatively, you can specify a specific dropdown to add this data to but passing -the data as the second argument and and the `id` of the trigger element as the first argument. +the data as the second argument and the `id` of the trigger element as the first argument. ```html <a href="#" data-dropdown-trigger="#list" id="trigger">Toggle</a> diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md index 7727bd74c3c..72abda26e3d 100644 --- a/doc/development/testing_guide/best_practices.md +++ b/doc/development/testing_guide/best_practices.md @@ -394,7 +394,7 @@ This is especially useful whenever it's showing 500 internal server error. ### Shared contexts -All shared contexts should be be placed under `spec/support/shared_contexts/`. +All shared contexts should be placed under `spec/support/shared_contexts/`. Shared contexts can be placed in subfolder if they apply to a certain type of specs only (e.g. features, requests etc.) but shouldn't be if they apply to multiple type of specs. @@ -404,7 +404,7 @@ Each file should include only one context and have a descriptive name, e.g. ### Shared examples -All shared examples should be be placed under `spec/support/shared_examples/`. +All shared examples should be placed under `spec/support/shared_examples/`. Shared examples can be placed in subfolder if they apply to a certain type of specs only (e.g. features, requests etc.) but shouldn't be if they apply to multiple type of specs. @@ -416,7 +416,7 @@ Each file should include only one context and have a descriptive name, e.g. Helpers are usually modules that provide some methods to hide the complexity of specific RSpec examples. You can define helpers in RSpec files if they're not -intended to be shared with other specs. Otherwise, they should be be placed +intended to be shared with other specs. Otherwise, they should be placed under `spec/support/helpers/`. Helpers can be placed in subfolder if they apply to a certain type of specs only (e.g. features, requests etc.) but shouldn't be if they apply to multiple type of specs. @@ -470,7 +470,7 @@ GitLab uses [factory_bot] as a test fixture replacement. ### Fixtures -All fixtures should be be placed under `spec/fixtures/`. +All fixtures should be placed under `spec/fixtures/`. ### Repositories |