Update the docs

Signed-off-by: Saksham Sharma <sakshamsharma630@gmail.com>

docs/getting-started/configuration.md

@@ -28,7 +28,7 @@ At the end of this tutorial, you can expect:
 
 These instructions can be skipped if you already have a PostgreSQL server
 installed and created a schema and user. The example below is for Linux, but
-luckily there's detailed instructions on how to
+luckily there are detailed instructions on how to
 [install PostgreSQL](https://www.postgresql.org/download/) to help you get
 started.
 
@@ -113,7 +113,7 @@ new component, or register an existing one it will be saved in the database.
 Later in this tutorial you'll add a service, and you can test if it's persistent
 as advertised.
 
-If you want to read more about the database configuration, here's some helpful
+If you want to read more about the database configuration, here are some helpful
 links:
 
 - [Configuring Plugin Databases](../tutorials/configuring-plugin-databases.md#privileges)
@@ -122,7 +122,7 @@ links:
 
 ### Setting up authentication
 
-There's multiple authentication providers available for you to use with
+There are multiple authentication providers available for you to use with
 Backstage, feel free to follow
 [the instructions for adding authentication](../auth/).
 
@@ -191,7 +191,7 @@ components: {
 That should be it. You can stop your Backstage App. When you start it again and
 go to your Backstage portal in your browser, you should have your login prompt!
 
-To learn more about Authentication in Backstage, there's the following docs you
+To learn more about Authentication in Backstage, here are the following docs you
 could read:
 
 - [Adding Authentication](../auth/)
@@ -208,7 +208,7 @@ and Groups can also be loaded from an organization. While using GitHub Apps
 might be the best way to set up integrations, for this tutorial you'll use a
 Personal Access Token.
 
-Create your Personal Access Token by opening the
+Create your Personal Access Token by opening
 [the GitHub token creation page](https://github.com/settings/tokens/new). Use a
 name to identify this token and put it in the notes field. Choose a number of
 days for expiration. If you have a hard time picking a number, we suggest to go

docs/overview/adopting.md

@@ -25,7 +25,7 @@ This team will have **four** primary objectives:
 
 2. Drive adoption of customers (developers at your company).
 
-3. Work with senior tech leadership and architects to ensure your organizations
+3. Work with senior tech leadership and architects to ensure your organization's
    best practices for software development are encoded into a set of
    [Software Templates](../features/software-templates/index.md).
 
@@ -62,7 +62,7 @@ products they maintain.
 
 ### Tactics
 
-Example of tactics we have used to evangelize Backstage internally:
+Examples of tactics we have used to evangelize Backstage internally:
 
 - Arrange "Lunch & Learns" and seminars. Frequently offer teams interested in
   Backstage development to come to a seminar where you show, for example, how to
@@ -77,13 +77,13 @@ Example of tactics we have used to evangelize Backstage internally:
 
 - Show & tell meetings. In order to build an internal community around Backstage
   we have quarterly meetings where anyone working on Backstage is invited to
-  present their work. This is a not only a great way to get early feedback, but
+  present their work. This is not only a great way to get early feedback, but
   also helps coordination between teams that are building overlapping
   experiences.
 
 - Provide metrics. Add instrumentation to your Backstage deployment and make
-  metrics available to contributing teams. At Spotify we have even gone so far
-  as sending out weekly digest email showing how usage metrics have changed for
+  metrics available to contributing teams. At Spotify, we have even gone so far
+  as to send out weekly digest emails showing how usage metrics have changed for
   individual plugins.
 
 - Pro-actively identify new plugins. Reach out to teams that own internal UIs or
@@ -109,12 +109,12 @@ successful impact on your software development process:
 - **Deploys to production** Cousin to the metric above: How many times does an
   engineer push changes into production.
 
-- **MTTR** With clear ownership of all the pieces in your micro services
+- **MTTR** With clear ownership of all the pieces in your microservices
   ecosystem and all tools integrated into one place, Backstage makes it quicker
   for teams to find the root cause of failures, and fix them.
 
 - **Context switching** Reducing context switching can help engineers stay in
-  the "zone". We measure the number of different tools an engineer have to
+  the "zone". We measure the number of different tools an engineer has to
   interact with in order to get a certain job done (e.g. push a change, follow
   it into production and validate it did not break anything).
 

docs/overview/roadmap.md

@@ -21,7 +21,7 @@ mean features in the radar, but not yet scheduled.
 
 The long-term roadmap (12 - 36 months) is not detailed in the public roadmap.
 Third-party contributions are also not currently included in the roadmap. Let us
-know about any ongoing developments and we’re happy to include it here as well.
+know about any ongoing developments and we’re happy to include them here as well.
 
 ## What’s next