Merge branch 'docs/tidy-up-chaos-endpoint' into 'master'

Followup edit of documentation

See merge request gitlab-org/gitlab-ce!30986

doc/development/chaos_endpoints.md

@@ -69,7 +69,7 @@ curl http://localhost:3000/-/chaos/leakmem?memory_mb=1024&duration_s=10&token=se
 
 This endpoint attempts to fully utilise a single core, at 100%, for the given period.
 
-Depending on your rack server setup, your request may timeout after a predermined period (normally 60 seconds).
+Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds).
 If you're using Unicorn, this is done by killing the worker process.
 
 ```
@@ -80,7 +80,7 @@ GET /-/chaos/cpu_spin?duration_s=50&async=true
 
 | Attribute    | Type    | Required | Description                                                           |
 | ------------ | ------- | -------- | --------------------------------------------------------------------- |
-| `duration_s` | integer | no       | Duration, in seconds, that the core will be utilised. Defaults to 30s |
+| `duration_s` | integer | no       | Duration, in seconds, that the core will be utilized. Defaults to 30s |
 | `async`      | boolean | no       | Set to true to consume CPU in a Sidekiq background worker process     |
 
 ```bash
@@ -93,7 +93,7 @@ curl http://localhost:3000/-/chaos/cpu_spin?duration_s=60&token=secret
 This endpoint attempts to fully utilise a single core, and interleave it with DB request, for the given period.
 This endpoint can be used to model yielding execution to another threads when running concurrently.
 
-Depending on your rack server setup, your request may timeout after a predermined period (normally 60 seconds).
+Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds).
 If you're using Unicorn, this is done by killing the worker process.
 
 ```
@@ -105,7 +105,7 @@ GET /-/chaos/db_spin?duration_s=50&async=true
 | Attribute    | Type    | Required | Description                                                                 |
 | ------------ | ------- | -------- | --------------------------------------------------------------------------- |
 | `interval_s` | float   | no       | Interval, in seconds, for every DB request. Defaults to 1s                  |
-| `duration_s` | integer | no       | Duration, in seconds, that the core will be utilised. Defaults to 30s       |
+| `duration_s` | integer | no       | Duration, in seconds, that the core will be utilized. Defaults to 30s       |
 | `async`      | boolean | no       | Set to true to perform the operation in a Sidekiq background worker process |
 
 ```bash

doc/development/reusing_abstractions.md

@@ -14,13 +14,13 @@ on maintainability, the ability to easily debug problems, or even performance.
 An example would be to use `ProjectsFinder` in `IssuesFinder` to limit issues to
 those belonging to a set of projects. While initially this may seem like a good
 idea, both classes provide a very high level interface with very little control.
-This means that `IssuesFinder` may not be able to produce a better optimised
+This means that `IssuesFinder` may not be able to produce a better optimized
 database query, as a large portion of the query is controlled by the internals
 of `ProjectsFinder`.
 
 To work around this problem, you would use the same code used by
 `ProjectsFinder`, instead of using `ProjectsFinder` itself directly. This allows
-you to compose your behaviour better, giving you more control over the behaviour
+you to compose your behavior better, giving you more control over the behavior
 of the code.
 
 To illustrate, consider the following code from `IssuableFinder#projects`:
@@ -52,7 +52,7 @@ functionality is added to this (high level) interface. Instead of _only_
 affecting the cases where this is necessary, it may also start affecting
 `IssuableFinder` in a negative way. For example, the query produced by
 `GroupProjectsFinder` may include unnecessary conditions. Since we're using a
-finder here, we can't easily opt-out of that behaviour. We could add options to
+finder here, we can't easily opt-out of that behavior. We could add options to
 do so, but then we'd need as many options as we have features. Every option adds
 two code paths, which means that for four features we have to cover 8 different
 code paths.
@@ -213,6 +213,5 @@ The API provided by Active Record itself, such as the `where` method, `save`,
 
 Everything in `app/workers`.
 
-The scheduling of Sidekiq jobs using `SomeWorker.perform_async`, `perform_in`,
-etc. Directly invoking a worker using `SomeWorker.new.perform` should be avoided
-at all times in application code, though this is fine to use in tests.
+Use `SomeWorker.perform_async` or `SomeWorker.perform_in` to schedule Sidekiq
+jobs. Never directly invoke a worker using `SomeWorker.new.perform`.