pr suggestions grammer and spelling

Signed-off-by: R-Lawton <rlawton@redhat.com>

Author: R-Lawton

rfcs/0000-observability-api.md

@@ -13,7 +13,7 @@ This is a proposal for adding the ability to configure aspects of observability
 # Motivation
 [motivation]: #motivation
 
-Users of Kuadrant (Platform engineers and or Site reliability engineers) will want a way to be able to configure different aspects of observability for Kuadrant without having to configure things at the component level themselves. Providing users this ability allows them to not have to have a deep knowledge of the inner workings of the components as well as integrate Kuadrant observability pieces with their own observability stack or Openshift user workload monitoring. Resulting in a fully comprehensive observability view all configured in one location.
+Users of Kuadrant (Platform engineers and or Site reliability engineers) will want a way to be able to configure different aspects of observability for Kuadrant without having to configure things at the component level themselves. Providing users this ability allows them to integrate Kuadrant observability pieces with their own observability stack or Openshift user workload monitoring without needing a deep knowledge of the inner workings of the components, resulting in a fully comprehensive observability view all configured in one location.
 
 # Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
@@ -59,7 +59,7 @@ spec:
 ```
 
 ### Status
-The status of the Kuadrant CR will not be the observability stack is in a "healthy" state i.e Prometheus and Grafana is up and running. It should be the status of only the things that we have control over. The status will show what components the user will have configured for example logging setup for Authorino and Limitador. We will not be taking responsibility for aspects we don't have control over. 
+The status of the Kuadrant CR will not be whether the observability stack is in a "healthy" state, i.e., Prometheus and Grafana is up and running. It should be the status of only the things that we have control over. The status will show what components the user has configured, for example, the logging setup for Authorino and Limitador. We will not be taking responsibility for aspects we don't have control over. 
 
 #### Example status:
 
@@ -80,11 +80,11 @@ metrics:
 
 In terms of how the information supplied in the Kuadrant CR will get passed to the other Kuadrant components, multiple options have been brought up:
 
-- directly - like setting flags or configuration directly on the deployments of the different Kuadrant components.
-- indirectly -  Passing the information to Authorino & Limitador via the Authorino & Limitador CRs
-- indirectly -  Passing the information to Authorino & Limitador in the form of there own Observability CRs
+1. directly - like setting flags or configuration directly on the deployments of the different Kuadrant components.
+2. indirectly -  Passing the information to Authorino & Limitador via the Authorino & Limitador CRs
+3. indirectly -  Passing the information to Authorino & Limitador in the form of their own Observability CRs
 
-The best approach would be the indirect approach, meaning once the Kuadrant CR is updated, the information is passed to the relevant component CR. For example the tracing section in the Authorino CR spec would be updated with the required endpoints and other configuration from the Kuadrant CR. This does mean that the spec exposed is whats in the Kuadrant component CR's but new changes can be requested and implemented in said components.
+The best approach would be the approach 2), an indirect approach, meaning once the Kuadrant CR is updated, the information is passed to the relevant component CR. For example the tracing section in the Authorino CR spec would be updated with the required endpoints and other configuration from the Kuadrant CR. This does mean that the spec exposed is whats in the Kuadrant component CR's, but new changes can be requested and implemented in said components.
 
 #### Adding, modifying and deleting values or no values
 
@@ -131,7 +131,7 @@ An other option that has been investigated which is very similar to above, is ha
 
 The reason why we should not go with the above method is reliance. The Observability CR will rely on the Kuadrant CR being present and we moving away from that model. From a user point of view having a users have to change configuration in 3+ separate crs in some cases, is tedious and slow.
 
-If we don't decide to any of these options the user will have to manually in multiple places add there configuration of their desired observability stack which can result in poor user experience, mistakes being made and values not being tracked properly.
+If we don't decide to go with any of these options, the user will have to manually add the configuration of their desired observability stack in multiple places, which can result in poor user experience, mistakes being made and values not being tracked properly.
 
 
 # Prior art