Fixes style and language issues in Product Intelligence pages

doc/development/service_ping/metrics_dictionary.md

@@ -218,7 +218,7 @@ The [Redis HLL metrics](implement.md#known-events-are-added-automatically-in-ser
 
 A YAML metric definition is required for each metric. A dedicated generator is provided to create metric definitions for Redis HLL events.
 
-The generator takes `category` and `event` arguments, as the root key will be `redis_hll_counters`, and creates two metric definitions for weekly and monthly timeframes:
+The generator takes `category` and `event` arguments, as the root key is `redis_hll_counters`, and creates two metric definitions for weekly and monthly time frames:
 
 ```shell
 bundle exec rails generate gitlab:usage_metric_definition:redis_hll issues i_closed

doc/development/service_ping/metrics_instrumentation.md

@@ -115,13 +115,13 @@ There is support for:
 - [Redis HLL metrics](#redis-hyperloglog-metrics).
 - [Generic metrics](#generic-metrics), which are metrics based on settings or configurations.
 
-Currently, there is no support for:
+There is no support for:
 
 - `add`, `sum`, `histogram` for database metrics.
 
 You can [track the progress to support these](https://gitlab.com/groups/gitlab-org/-/epics/6118).
 
-## Creating a new metric instrumentation class
+## Create a new metric instrumentation class
 
 To create a stub instrumentation for a Service Ping metric, you can use a dedicated [generator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_generator.rb):
 

doc/development/service_ping/metrics_lifecycle.md

@@ -39,7 +39,7 @@ For GitLab 12.6, the metric was changed to filter out archived projects:
 }
 ```
 
-In this scenario all instances running up to GitLab 12.5 continue to report `example_metric`,
+In this scenario, all instances running up to GitLab 12.5 continue to report `example_metric`,
 including all archived projects, while all instances running GitLab 12.6 and higher filters
 out such projects. As Service Ping data is collected from all reporting instances, the
 resulting dataset includes mixed data, which distorts any following business analysis.

doc/development/snowplow/review_guidelines.md

@@ -26,7 +26,7 @@ events or touches Snowplow related files.
 #### The merge request **author** should
 
 - For frontend events, when relevant, add a screenshot of the event in
-  the [testing tool](../snowplow/index.md#developing-and-testing-snowplow) used.
+  the [testing tool](../snowplow/index.md#develop-and-test-snowplow) used.
 - For backend events, when relevant, add the output of the
   [Snowplow Micro](index.md#snowplow-mini) good events
   `GET http://localhost:9090/micro/good` (it might be a good idea
@@ -39,5 +39,5 @@ events or touches Snowplow related files.
 - Check the [usage recommendations](../snowplow/index.md#usage-recommendations).
 - Check that the [Event Dictionary](event_dictionary_guide.md) is up-to-date.
 - If needed, check that the events are firing locally using one of the
-[testing tools](../snowplow/index.md#developing-and-testing-snowplow) available.
+[testing tools](../snowplow/index.md#develop-and-test-snowplow) available.
 - Approve the MR, and relabel the MR with `~"product intelligence::approved"`.