Clean up substitution warning 2

doc/api/freeze_periods.md

@@ -94,7 +94,7 @@ POST /projects/:id/freeze_periods
 | `id`               | integer or string  | yes                         | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding).                                              |
 | `freeze_start`     | string          | yes                         | Start of the Freeze Period in [cron](https://crontab.guru/) format.                                                              |
 | `freeze_end`       | string          | yes                         | End of the Freeze Period in [cron](https://crontab.guru/) format.                                                                |
-| `cron_timezone`    | string          | no                          | The timezone for the cron fields, defaults to UTC if not provided.                                                               |
+| `cron_timezone`    | string          | no                          | The time zone for the cron fields, defaults to UTC if not provided.                                                               |
 
 Example request:
 
@@ -131,7 +131,7 @@ PUT /projects/:id/freeze_periods/:freeze_period_id
 | `freeze_period_id`    | integer or string          | yes      | The database ID of the Freeze Period.                                                              |
 | `freeze_start`     | string          | no                         | Start of the Freeze Period in [cron](https://crontab.guru/) format.                                                              |
 | `freeze_end`       | string          | no                         | End of the Freeze Period in [cron](https://crontab.guru/) format.                                                                |
-| `cron_timezone`    | string          | no                          | The timezone for the cron fields.                                                               |
+| `cron_timezone`    | string          | no                          | The time zone for the cron fields.                                                               |
 
 Example request:
 

doc/api/groups.md

@@ -830,7 +830,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
 
 ## Transfer project to group
 
-Transfer a project to the Group namespace. Available only to instance administrators, although an [alternative API endpoint](projects.md#transfer-a-project-to-a-new-namespace) is available which does not require instance administrator access. Transferring projects may fail when tagged packages exist in the project's repository.
+Transfer a project to the Group namespace. Available only to instance administrators, although an [alternative API endpoint](projects.md#transfer-a-project-to-a-new-namespace) is available which does not require instance administrator role. Transferring projects may fail when tagged packages exist in the project's repository.
 
 ```plaintext
 POST  /groups/:id/projects/:project_id

doc/api/plan_limits.md

@@ -14,7 +14,7 @@ The existing plans depend on the GitLab edition. In the Community Edition, only
 is available. In the Enterprise Edition, additional plans are available as well.
 
 NOTE:
-Administrator access is required to use this API.
+The Administrator role is required to use this API.
 
 ## Get current plan limits
 

doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md

@@ -514,7 +514,7 @@ Today, loading GraphQL requires a bunch of [dependencies](https://gitlab.com/git
 
 GraphQL only needs to run in a specific context. If we could limit when it is being loaded we could effectively improve application efficiency, by reducing application load time and required memory. This, for example, is applicable for every size installation.
 
-A potential challenge with GraphQL and Websockets is that at some point we might want to use Action Cable subscriptions and push GraphQL/API payload from Sidekiq to clients. This would likely utilize Redis to pass data through. Where Sidekiq would publish information on Redis and ActionCable Node would pass through that information to connected clients. This way of working is possible in the above model, but we would have to use GraphQL or API (over HTTP endpoint) to calculate what should be sent.
+A potential challenge with GraphQL and Websockets is that at some point we might want to use Action Cable subscriptions and push GraphQL/API payload from Sidekiq to clients. This would likely use Redis to pass data through. Where Sidekiq would publish information on Redis and ActionCable Node would pass through that information to connected clients. This way of working is possible in the above model, but we would have to use GraphQL or API (over HTTP endpoint) to calculate what should be sent.
 
 An alternative way is to use a notification system that would always make an `ActionCable` node (the one handling WebSockets) generate a payload based on a send query instead of performing passthrough. This could be applicable since `ActionCable` is the one handling a given connection for a client. This could have a downside of having to recalculate the same payload if many clients would be watching the same resource. However, this behavior of system might still be desired for security purposes, as generated payload might be dependent on permission of watching client (we would show different for anonymous, and different for the member of the project).
 

doc/architecture/blueprints/consolidating_groups_and_projects/index.md

@@ -32,7 +32,7 @@ they all live on their own. A few more problems with this approach:
 - Features are coupled to their container. In practice it is not straight
   forward to decouple a feature from its container. The degree of coupling
   varies across features.
-- Naive duplication of features will result in a more complex and fragile code base.
+- Naive duplication of features will result in a more complex and fragile codebase.
 - Generalizing solutions across groups and projects may degrade system performance.
 - The range of features span across many teams, and these changes will need to
   manage development interference.