Merge pull request #14790 from Braundo/main

inclusive terms

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.