inclusive terms

Signed-off-by: aaronbraundmeier@gmail.com <aaronbraundmeier@gmail.com>
Signed-off-by: Fredrik Adelöw <freben@gmail.com>

docs/FAQ.md

@@ -54,7 +54,7 @@ begun work on various aspects of all three phases. Looking at the
 [milestones for active issues](https://github.com/backstage/backstage/milestones)
 will also give you a sense of our progress.
 
-### My company doesn't have thousands of developers or services. Is Backstage overkill?
+### My company doesn't have thousands of developers or services. Is using Backstage excessive for our needs?
 
 Not at all! A core reason to adopt Backstage is to standardize how software is
 built at your company. It's easier to decide on those standards as a small

docs/architecture-decisions/adr010-luxon-date-library.md

@@ -10,7 +10,7 @@ description: Architecture Decision Record (ADR) for Luxon Date Library
 Date formatting (e.g. `a day ago`) and calculations are common within Backstage.
 Some of these useful features are not supported by the standard JavaScript
 `Date` object. The popular [Moment.js](https://momentjs.com/) library has been
-commonly used to fill this gap but suffers from large bundle sizes and mutable
+commonly used to fill this gap but is affected by large bundle sizes and mutable
 state issues. On top of this, `momentjs` is
 [being sunset](https://momentjs.com/docs/#/-project-status/) and the project
 recommends using one of the more modern alternative libraries.

docs/auth/cloudflare/access.md

@@ -63,7 +63,7 @@ export default async function createPlugin(
           // and the access token and produces the Backstage token with the
           // relevant user info.
           async resolver({ profile, result }, ctx) {
-            // Somehow compute the Backstage token claims. Just some dummy code
+            // Somehow compute the Backstage token claims. Just some sample code
             // shown here, but you may want to query your LDAP server, or
             // https://<teamName>.cloudflareaccess.com/cdn-cgi/access/get-identity
             // https://developers.cloudflare.com/cloudflare-one/identity/users/validating-json/#groups-within-a-jwt

docs/auth/google/gcp-iap-auth.md

@@ -70,7 +70,7 @@ export default async function createPlugin(
           // and the IAP token and produces the Backstage token with the
           // relevant user info.
           async resolver({ profile, result: { iapToken } }, ctx) {
-            // Somehow compute the Backstage token claims. Just some dummy code
+            // Somehow compute the Backstage token claims. Just some sample code
             // shown here, but you may want to query your LDAP server, or
             // GSuite or similar, based on the IAP token sub/email claims
             const id = iapToken.email.split('@')[0];

docs/deployment/k8s.md

@@ -256,7 +256,7 @@ bash-5.1# exit
 
 The database pod is running, but how does another pod connect to it?
 
-Kubernetes pods are transient - they can be killed, restarted, or created
+Kubernetes pods are transient - they can be stopped, restarted, or created
 dynamically. Therefore we don't want to try to connect to pods directly, but
 rather create a Kubernetes Service. Services keep track of pods and direct
 traffic to the right place.

docs/features/software-catalog/system-model.md

@@ -50,7 +50,7 @@ components need to be in a known machine-readable format so we can build further
 tooling and analysis on top.
 
 APIs have a visibility: they are either public (making them available for any
-other component to consume), restricted (only available to a whitelisted set of
+other component to consume), restricted (only available to an allowlisted set of
 consumers), or private (only available within their system). As public APIs are
 going to be the primary way interaction between components, Backstage supports
 documenting, indexing and searching all APIs so we can browse them as

docs/overview/architecture-overview.md

@@ -260,7 +260,7 @@ development dependency only.
 
 It can sometimes be difficult to decide where to place your plugin code. For example
 should it go directly in the `-backend` plugin package or in the `-node` package?
-As a rule of thumb you should try to keep the exposure of your code as low
+As a general guideline you should try to keep the exposure of your code as low
 as possible. If it doesn't need to be public API, it's best to avoid. If you don't
 need it to be used by other plugins, then keep it directly in the plugin packages.
 

docs/plugins/backend-plugin.md

@@ -51,7 +51,7 @@ terminal window, now run
 curl localhost:7007/carmen/health
 ```
 
-This should return `{"status":"ok"}`. Success! Press `Ctrl + c` to kill it
+This should return `{"status":"ok"}`. Success! Press `Ctrl + c` to stop it
 again.
 
 ## Developing your Backend Plugin

docs/plugins/testing.md

@@ -123,7 +123,7 @@ than simply letting them know they had an invalid input.
 > input change.
 
 This piggybacks the Scalability Principle and applies primarily to frontend
-development. As a general rule of thumb, frontends should be flexible enough so
+development. As a general guideline, frontends should be flexible enough so
 that the UX or design can change while touching the least amount of code
 possible. So for example, a poor unit test would verify the color of a button
 when it is hovered. This would be a poor unit test, because if you decide to
@@ -353,7 +353,7 @@ For more information:
 ### Accessing `store`, `theme`, routing, browser history, etc.
 
 The Backstage application has several core providers at its root. To run your
-test wrapped in a "dummy" Backstage application, you can use our utility
+test wrapped in a "sample" Backstage application, you can use our utility
 functions:
 
 **`wrapInTestApp`**

docs/plugins/url-reader.md

@@ -268,7 +268,7 @@ async function main() {
 ```
 
 This will be run every time you restart the backend. Note that after any change
-in the URL Reader code, you need to kill the backend and restart, since the
+in the URL Reader code, you need to stop the backend and restart, since the
 `reader` instance is memoized and does not update on hot module reloading. Also,
 there are a lot of unit tests written for the URL Readers, which you can make
 use of.