Improving readability and tone by removing condescending phrases

Author: puneet-ekline

content/en/docs/collector/building/connector.md

@@ -64,7 +64,7 @@ following links:
 
 For this tutorial, we will write an example connector that takes traces and
 converts them into metrics as a basic example of how the connector component in
-OpenTelemetry functions. The functionality of the basic connector is to simply
+OpenTelemetry functions. The functionality of the basic connector is to
 count the number of spans in traces that contain a specific attribute name. The
 count of these occurrences are stored in the connector.
 

content/en/docs/collector/building/receiver.md

@@ -75,7 +75,7 @@ this:
 In order to properly test your trace receiver, you may need a distributed
 tracing backend so the Collector can send the telemetry to it. We will be using
 [Jaeger](https://www.jaegertracing.io/docs/latest/getting-started/), if you
-don't have a `Jaeger` instance running, you can easily start one using Docker
+don't have a `Jaeger` instance running, you can start one using Docker
 with the following command:
 
 ```sh

content/en/docs/collector/custom-collector.md

@@ -111,7 +111,7 @@ Here are the tags for the `dist` map:
 As you can see on the table above, all the `dist` tags are optional, so you will
 be adding custom values for them depending if your intentions to make your
 custom Collector distribution available for consumption by other users or if you
-are simply leveraging the `ocb` to bootstrap your component development and
+are leveraging the `ocb` to bootstrap your component development and
 testing environment.
 
 For this tutorial, you will be creating a Collector's distribution to support
@@ -214,7 +214,7 @@ The folder structure should look like this:
 ```
 
 You can now use the generated code to bootstrap your component development
-projects and easily build and distribute your own collector distribution with
+projects and build and distribute your own collector distribution with
 your components.
 
 Further reading:

content/en/docs/collector/internal-telemetry.md

@@ -136,7 +136,7 @@ journalctl | grep otelcol | grep Error
 
 ## Types of internal telemetry
 
-The OpenTelemetry Collector aims to be a model of observable service by clearly
+The OpenTelemetry Collector aims to be a model of observable service by
 exposing its own operational metrics. Additionally, it collects host resource
 metrics that can help you understand if problems are caused by a different
 process on the same host. Specific components of the Collector can also emit

content/en/docs/collector/management.md

@@ -82,11 +82,11 @@ Let's have a look at a concrete setup:
    the server-side OpAMP part and the collector (or a supervisor controlling the
    collector) implementing OpAMP client-side.
 
-You can try out a simple OpAMP setup yourself by using the [OpAMP protocol
+You can try out an OpAMP setup yourself by using the [OpAMP protocol
 implementation in Go][opamp-go]. For the following walkthrough you will need to
 have Go in version 1.19 or above available.
 
-We will set up a simple OpAMP control plane consisting of an example OpAMP
+We set up an OpAMP control plane consisting of an example OpAMP
 server and let an OpenTelemetry Collector connect to it via an example OpAMP
 supervisor.
 

content/en/docs/collector/scaling.md

@@ -229,7 +229,7 @@ spec:
 Some receivers are actively obtaining telemetry data to place in the pipeline,
 like the hostmetrics and prometheus receivers. While getting host metrics isn’t
 something we’d typically scale up, we might need to split the job of scraping
-thousands of endpoints for the Prometheus receiver. And we can’t simply add more
+thousands of endpoints for the Prometheus receiver. And we can’t add more
 instances with the same configuration, as each Collector would try to scrape the
 same endpoints as every other Collector in the cluster, causing even more
 problems, like out-of-order samples.

content/en/docs/concepts/observability-primer.md

@@ -9,7 +9,7 @@ cSpell:ignore: webshop
 
 Observability lets you understand a system from the outside by letting you ask
 questions about that system without knowing its inner workings. Furthermore, it
-allows you to easily troubleshoot and handle novel problems, that is, "unknown
+allows you to troubleshoot and handle novel problems, that is, "unknown
 unknowns”. It also helps you answer the question "Why is this happening?"
 
 To ask those questions about your system, your application must be properly

content/en/docs/concepts/signals/traces.md

@@ -282,7 +282,7 @@ meaningful, singular point in time.
 #### When to use span events versus span attributes
 
 Since span events also contain attributes, the question of when to use events
-instead of attributes might not always have an obvious answer. To inform your
+instead of attributes might not always have a clear answer. To inform your
 decision, consider whether a specific timestamp is meaningful.
 
 For example, when you're tracking an operation with a span and the operation

content/en/docs/demo/collector-data-flow-dashboard/index.md

@@ -97,7 +97,7 @@ the data flow.
 
 ### Export Ratio
 
-Export ratio is basically the ratio between receiver and exporter metrics. You
+Export ratio is the ratio between receiver and exporter metrics. You
 can notice over the dashboard screenshot above that the export ratio on metrics
 is way too high than the received metrics. This is because the demo application
 is configured to generate span metrics which is a processor that generates

content/en/docs/demo/requirements/architecture.md

@@ -24,7 +24,7 @@ customization by end-users, vendors, and other stakeholders.
 - Provide developers with a robust sample application they can use in learning
   OpenTelemetry instrumentation.
 - Provide observability vendors with a single, well-supported, demo platform
-  that they can further customize (or simply use OOB).
+  that they can further customize (or use OOB).
 - Provide the OpenTelemetry community with a living artifact that demonstrates
   the features and capabilities of OTel APIs, SDKs, and tools.
 - Provide OpenTelemetry maintainers and WGs a platform to demonstrate new

content/en/docs/kubernetes/collector/components.md

@@ -267,7 +267,7 @@ Kubernetes-specific receiver, it is still the de facto solution for collecting
 any logs from Kubernetes.
 
 The Filelog Receiver is composed of Operators that are chained together to
-process a log. Each Operator performs a simple responsibility, such as parsing a
+process a log. Each Operator performs a responsibility, such as parsing a
 timestamp or JSON. Configuring a Filelog Receiver is not trivial. If you're
 using the [OpenTelemetry Collector Helm chart](../../helm/collector/) you can
 use the [`logsCollection` preset](../../helm/collector/#logs-collection-preset)

content/en/docs/kubernetes/helm/demo.md

@@ -7,7 +7,7 @@ The [OpenTelemetry Demo](/docs/demo/) is a microservice-based distributed system
 intended to illustrate the implementation of OpenTelemetry in a near real-world
 environment. As part of that effort, the OpenTelemetry community create the
 [OpenTelemetry Demo Helm Chart](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-demo)
-so that it can be easily installed in Kubernetes.
+so that it can be installed in Kubernetes.
 
 ## Configuration
 

content/en/docs/languages/cpp/getting-started.md

@@ -7,7 +7,7 @@ weight: 10
 
 This page will show you how to get started with OpenTelemetry in C++.
 
-You will learn how to instrument a simple C++ application, such that
+You learn how to instrument a C++ application, such that
 [traces](/docs/concepts/signals/traces/) are emitted to the terminal.
 
 ## Prerequisites

content/en/docs/languages/go/instrumentation.md

@@ -210,7 +210,7 @@ mutex.Unlock()
 ```
 
 A useful characteristic of events is that their timestamps are displayed as
-offsets from the beginning of the span, allowing you to easily see how much time
+offsets from the beginning of the span, allowing you to see how much time
 elapsed between them.
 
 Events can also have attributes of their own -

content/en/docs/languages/go/resources.md

@@ -26,7 +26,7 @@ provider := sdktrace.NewTracerProvider(
 Note the use of the `semconv` package to provide
 [conventional names](/docs/concepts/semantic-conventions/) for resource
 attributes. This helps ensure that consumers of telemetry produced with these
-semantic conventions can easily discover relevant attributes and understand
+semantic conventions can discover relevant attributes and understand
 their meaning.
 
 Resources can also be detected automatically through `resource.Detector`

content/en/docs/languages/java/getting-started.md

@@ -9,7 +9,7 @@ weight: 10
 
 This page will show you how to get started with OpenTelemetry in Java.
 
-You will learn how you can instrument a simple Java application automatically,
+You learn how you can instrument a Java application automatically,
 in such a way that [traces][], [metrics][], and [logs][] are emitted to the
 console.
 

content/en/docs/languages/js/getting-started/browser.md

@@ -252,5 +252,5 @@ registerInstrumentations({
 
 ## Meta Packages for Web
 
-To leverage the most common instrumentations all in one you can simply use the
+To leverage the most common instrumentations all in one you can use the
 [OpenTelemetry Meta Packages for Web](https://www.npmjs.com/package/@opentelemetry/auto-instrumentations-web)

content/en/docs/languages/php/getting-started.md

@@ -10,7 +10,7 @@ OpenTelemetry for PHP can be used to generate and export [traces][], [metrics][]
 and [logs][].
 
 This page will show you how to get started with OpenTelemetry in PHP. We will
-create a simple "roll the dice" application, then apply both zero-code and code
+create a "roll the dice" application, then apply both zero-code and code
 based instrumentation to generate [traces][] and export them to the console. We
 will then emit some [logs][] which will also be sent to the console.
 

content/en/docs/languages/python/getting-started.md

@@ -8,7 +8,7 @@ weight: 10
 
 This page will show you how to get started with OpenTelemetry in Python.
 
-You will learn how you can instrument a simple application automatically, in
+You learn how you can instrument an application automatically, in
 such a way that [traces][], [metrics][], and [logs][] are emitted to the
 console.
 
@@ -292,7 +292,7 @@ following:
 Automatic instrumentation captures telemetry at the edges of your systems, such
 as inbound and outbound HTTP requests, but it doesn't capture what's going on in
 your application. For that you'll need to write some
-[manual instrumentation](../instrumentation/). Here's how you can easily link up
+[manual instrumentation](../instrumentation/). Here's how you can link up
 manual instrumentation with automatic instrumentation.
 
 ### Traces

content/en/docs/languages/ruby/instrumentation.md

@@ -222,7 +222,7 @@ end
 ```
 
 A useful characteristic of events is that their timestamps are displayed as
-offsets from the beginning of the span, allowing you to easily see how much time
+offsets from the beginning of the span, allowing you to see how much time
 elapsed between them.
 
 Events can also have attributes of their own e.g.

content/en/docs/languages/rust/getting-started.md

@@ -6,7 +6,7 @@ weight: 10
 
 This page will show you how to get started with OpenTelemetry in Rust.
 
-You will learn how you can instrument a simple Rust application, in such a way
+You learn how you can instrument a Rust application, in such a way
 that [traces][] are emitted to the console.
 
 ## Prerequisites