Commit fc74a4b1 authored by Bill Foster's avatar Bill Foster

Replacing "rule of thumb" with "guideline" in the docs

parent 42cd0687
...@@ -166,7 +166,7 @@ that can also be promoted in case of disaster. ...@@ -166,7 +166,7 @@ that can also be promoted in case of disaster.
## Deviating from the suggested reference architectures ## Deviating from the suggested reference architectures
As a general rule of thumb, the further away you move from the Reference Architectures, As a general guideline, the further away you move from the Reference Architectures,
the harder it will be get support for it. With any deviation, you're introducing the harder it will be get support for it. With any deviation, you're introducing
a layer of complexity that will add challenges to finding out where potential a layer of complexity that will add challenges to finding out where potential
issues might lie. issues might lie.
......
...@@ -308,7 +308,7 @@ This folder holds all components that are specific to this new feature. ...@@ -308,7 +308,7 @@ This folder holds all components that are specific to this new feature.
If you need to use or create a component that is likely to be used somewhere If you need to use or create a component that is likely to be used somewhere
else, please refer to `vue_shared/components`. else, please refer to `vue_shared/components`.
A good rule of thumb to know when you should create a component is to think if A good guideline to know when you should create a component is to think if
it could be reusable elsewhere. it could be reusable elsewhere.
For example, tables are used in a quite amount of places across GitLab, a table For example, tables are used in a quite amount of places across GitLab, a table
...@@ -336,7 +336,7 @@ In the [Vue documentation](https://vuejs.org/v2/api/#Options-Data) the Data func ...@@ -336,7 +336,7 @@ In the [Vue documentation](https://vuejs.org/v2/api/#Options-Data) the Data func
> The data object for the Vue instance. Vue recursively converts its properties into getter/setters > The data object for the Vue instance. Vue recursively converts its properties into getter/setters
to make it "reactive". The object must be plain: native objects such as browser API objects and to make it "reactive". The object must be plain: native objects such as browser API objects and
prototype properties are ignored. A rule of thumb is that data should just be data - it is not prototype properties are ignored. A guideline is that data should just be data - it is not
recommended to observe objects with their own stateful behavior. recommended to observe objects with their own stateful behavior.
Based on the Vue guidance: Based on the Vue guidance:
......
...@@ -57,7 +57,7 @@ Redis version 6.0 or higher is recommended, as this is what ships with ...@@ -57,7 +57,7 @@ Redis version 6.0 or higher is recommended, as this is what ships with
### Storage ### Storage
The necessary hard drive space largely depends on the size of the repositories you want to store in GitLab but as a *rule of thumb* you should have at least as much free space as all your repositories combined take up. The necessary hard drive space largely depends on the size of the repositories you want to store in GitLab but as a *guideline* you should have at least as much free space as all your repositories combined take up.
The Omnibus GitLab package requires about 2.5 GB of storage space for installation. The Omnibus GitLab package requires about 2.5 GB of storage space for installation.
......
...@@ -56,7 +56,7 @@ increasing the number of Sidekiq workers that can process jobs in the ...@@ -56,7 +56,7 @@ increasing the number of Sidekiq workers that can process jobs in the
`background_migration` queue. To see the size of this queue, `background_migration` queue. To see the size of this queue,
[Check for background migrations before upgrading](index.md#checking-for-background-migrations-before-upgrading). [Check for background migrations before upgrading](index.md#checking-for-background-migrations-before-upgrading).
As a rule of thumb, any database smaller than 10 GB doesn't take too much time to As a guideline, any database smaller than 10 GB doesn't take too much time to
upgrade; perhaps an hour at most per minor release. Larger databases however may upgrade; perhaps an hour at most per minor release. Larger databases however may
require more time, but this is highly dependent on the size of the database and require more time, but this is highly dependent on the size of the database and
the migrations that are being performed. the migrations that are being performed.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment