Style edits for Concepts section (#4550)

Author: theletterf

content/en/docs/concepts/_index.md

@@ -6,5 +6,5 @@ aliases: [concepts/overview]
 weight: 2
 ---
 
-In this section you'll learn about the data sources and key components of the
-OpenTelemetry project. This will help you understanding how OpenTelemetry works.
+This section covers data sources and key components of the OpenTelemetry
+project, which can help you understand how OpenTelemetry works.

content/en/docs/concepts/components.md

@@ -15,8 +15,8 @@ OpenTelemetry is currently made up of several main components:
   - [Zero-Code Instrumentation](#zero-code-instrumentation)
   - [Resource Detectors](#resource-detectors)
   - [Cross Service Propagators](#cross-service-propagators)
-  - [Sampler](#sampler)
-- [K8s operator](#k8s-operator)
+  - [Samplers](#samplers)
+- [Kubernetes operator](#kubernetes-operator)
 - [Function as a Service assets](#function-as-a-service-assets)
 
 OpenTelemetry lets you replace the need for vendor-specific SDKs and tools for
@@ -58,69 +58,69 @@ instrumentation in your application.
 
 For more information, see [Instrumenting](/docs/concepts/instrumentation/).
 
-### Instrumentation Libraries
+### Instrumentation libraries
 
 OpenTelemetry supports a broad number of components that generate relevant
 telemetry data from popular libraries and frameworks for supported languages.
-For example, inbound and outbound HTTP requests from an HTTP library will
-generate data about those requests.
+For example, inbound and outbound HTTP requests from an HTTP library generate
+data about those requests.
 
-It is a long-term goal that popular libraries are authored to be observable out
-of the box, such that pulling in a separate component is not required.
+An aspirational goal of OpenTelemetry is that all popular libraries are built to
+be observable by default, so that separate dependencies are not required.
 
 For more information, see
-[Instrumenting Libraries](/docs/concepts/instrumentation/libraries/).
+[Instrumenting libraries](/docs/concepts/instrumentation/libraries/).
 
 ### Exporters
 
 {{% docs/languages/exporters/intro %}}
 
-### Zero-Code Instrumentation
+### Zero-code instrumentation
 
-If applicable a language specific implementation of OpenTelemetry will provide a
+If applicable, a language specific implementation of OpenTelemetry provides a
 way to instrument your application without touching your source code. While the
-underlying mechanism depends on the language, at a minimum this will add the
-OpenTelemetry API and SDK capabilities to your application. Additionally they
-may add a set of Instrumentation Libraries and exporter dependencies.
+underlying mechanism depends on the language, zero-code instrumentation adds the
+OpenTelemetry API and SDK capabilities to your application. Additionally, it
+might add a set of instrumentation libraries and exporter dependencies.
 
 For more information, see
-[Zero-Code Instrumentation](/docs/concepts/instrumentation/zero-code/).
+[Zero-code instrumentation](/docs/concepts/instrumentation/zero-code/).
 
-### Resource Detectors
+### Resource detectors
 
 A [resource](/docs/concepts/resources/) represents the entity producing
-telemetry as resource attributes. For example, a process producing telemetry
+telemetry as resource attributes. For example, a process that produces telemetry
 that is running in a container on Kubernetes has a Pod name, a namespace, and
-possibly a deployment name. All three of these attributes can be included in the
+possibly a deployment name. You can include all these attributes in the
 resource.
 
 The language specific implementations of OpenTelemetry provide resource
-detection from the environment variable `OTEL_RESOURCE_ATTRIBUTES` and for many
-common entities, like process runtime, service, host or operating system.
+detection from the `OTEL_RESOURCE_ATTRIBUTES` environment variable and for many
+common entities, like process runtime, service, host, or operating system.
 
 For more information, see [Resources](/docs/concepts/resources/).
 
-### Cross Service Propagators
+### Cross-service propagators
 
 Propagation is the mechanism that moves data between services and processes.
-Although not limited to tracing, it is what allows traces to build causal
+Although not limited to tracing, propagation allows traces to build causal
 information about a system across services that are arbitrarily distributed
 across process and network boundaries.
 
-For the vast majority of the use cases, context propagation is done for you
-through Instrumentation Libraries. But, if needed you can use `Propagators`
-yourself to serialize and deserialize cross-cutting concerns such as the context
-of a span and [baggage](/docs/concepts/signals/baggage/).
+For the vast majority of the use cases, context propagation happens through
+instrumentation libraries. If needed, you can use propagators yourself to
+serialize and deserialize cross-cutting concerns such as the context of a span
+and [baggage](/docs/concepts/signals/baggage/).
 
-### Sampler
+### Samplers
 
 Sampling is a process that restricts the amount of traces that are generated by
-a system. The language-specific implementations offer several
-[head samplers](/docs/concepts/sampling/#head-sampling)
+a system. Each language-specific implementation of OpenTelemetry offers several
+[head samplers](/docs/concepts/sampling/#head-sampling).
 
 For more information, see [Sampling](/docs/concepts/sampling).
 
-## K8s operator
+## Kubernetes operator
 
 The OpenTelemetry Operator is an implementation of a Kubernetes Operator. The
 operator manages the OpenTelemetry Collector and auto-instrumentation of the
@@ -131,7 +131,7 @@ For more information, see [K8s Operator](/docs/kubernetes/operator/).
 ## Function as a Service assets
 
 OpenTelemetry supports various methods of monitoring Function-as-a-Service
-provided by different cloud vendors The OpenTelemetry community currently
+provided by different cloud vendors. The OpenTelemetry community currently
 provides pre-built Lambda layers able to auto-instrument your application as
 well as a the option of standalone Collector Lambda layer that can be used when
 instrumenting applications manually or automatically.

content/en/docs/concepts/context-propagation.md

@@ -1,38 +1,39 @@
 ---
-title: Context Propagation
+title: Context propagation
 weight: 10
 description: Learn about the concept that enables Distributed Tracing.
 ---
 
-With Context Propagation, [Signals](/docs/concepts/signals) can be correlated
+With context propagation, [Signals](/docs/concepts/signals) can be correlated
 with each other, regardless of where they are generated. Although not limited to
-tracing, it is what allows [traces](/docs/concepts/signals/traces) to build
-causal information about a system across services that are arbitrarily
+tracing, context propagation allows [traces](/docs/concepts/signals/traces) to
+build causal information about a system across services that are arbitrarily
 distributed across process and network boundaries.
 
-We define Context Propagation by two sub-concepts: Context and Propagation.
+To understand context propagation, you need to understand two separate concepts:
+context and propagation.
 
 ## Context
 
-A **Context** is an object that contains the information for the sending and
-receiving service (or
-[execution unit](/docs/specs/otel/glossary/#execution-unit)) to correlate one
-signal with another.
+Context is an object that contains the information for the sending and receiving
+service, or [execution unit](/docs/specs/otel/glossary/#execution-unit), to
+correlate one signal with another.
 
-For example, if Service A calls Service B, then a span from Service A whose ID
+For example, if service A calls service B, then a span from service A whose ID
 is in context will be used as the parent span for the next span created in
-Service B. The trace ID that is in context will be used for the next span
-created in Service B as well, which signifies that the span is part of the same
-trace as the span from Service A.
+service B. The trace ID that is in context will be used for the next span
+created in service B as well, which means that the span is part of the same
+trace as the span from service A.
 
 ## Propagation
 
-**Propagation** is the mechanism that moves context between services and
-processes. It serializes or deserializes the context object and provides the
-relevant information to be propagated from one service to another. Propagation
-is usually handled by instrumentation libraries and is transparent to the user,
-but in the event that you need to manually propagate context, you can use
-Propagation APIs.
+Propagation is the mechanism that moves context between services and processes.
+It serializes or deserializes the context object and provides the relevant
+information to be propagated from one service to another.
+
+Propagation is usually handled by instrumentation libraries and is transparent
+to the user. In the event that you need to manually propagate context, you can
+use Propagation APIs.
 
 OpenTelemetry maintains several official propagators. The default propagator is
 using the headers specified by the

content/en/docs/concepts/distributions.md

@@ -13,14 +13,15 @@ OpenTelemetry is available as:
 - [Language-specific instrumentation libraries](../instrumentation)
 - A [Collector binary](/docs/concepts/components/#collector)
 
-From any reference implementation a distribution may be created.
+Any reference implementation can be customized as a distribution.
 
 ## What is a distribution?
 
-A distribution, not to be confused with a fork, is customized version of an
-OpenTelemetry component. A distribution is a wrapper around an upstream
-OpenTelemetry repository with some customizations. Customizations in a
-distribution may include:
+A distribution is a customized version of an OpenTelemetry component. A
+distribution is a wrapper around an upstream OpenTelemetry repository with some
+customizations. Distributions are not to be confused with forks.
+
+Customizations in a distribution may include:
 
 - Scripts to ease use or customize use for a specific backend or vendor
 - Changes to default settings required for a backend, vendor, or end-user
@@ -29,29 +30,27 @@ distribution may include:
 - Additional capabilities beyond what OpenTelemetry provides
 - Less capabilities from what OpenTelemetry provides
 
-Distributions would broadly fall into the following categories:
+Distributions broadly fall into the following categories:
 
 - **"Pure":** These distributions provide the same functionality as upstream and
-  are 100% compatible. Customizations would typically be to ease of use or
+  are 100% compatible. Customizations typically enhance the ease of use or
   packaging. These customizations may be backend, vendor, or end-user specific.
-- **"Plus":** These distributions provide the same functionality as upstream
-  plus more. Customizations beyond those found in pure distributions would be
-  the inclusion of additional components. Examples of this would include
-  instrumentation libraries or vendor exporters not upstreamed to the
-  OpenTelemetry project.
-- **"Minus":** These distributions provide a reduced set of functionality from
-  upstream. Examples of this would include the removal of instrumentation
-  libraries or receivers/processors/exporters/extensions found in the
-  OpenTelemetry Collector project. These distributions may be provided to
-  increase supportability and security considerations.
-
-## Who would create a distribution?
-
-Anyone could create a distribution. Today, several
-[vendors](/ecosystem/vendors/) offer [distributions](/ecosystem/distributions/).
-In addition, end-users can consider creating a distribution if they wish to use
-components in the [Registry](/ecosystem/registry/) that are not upstreamed to
-the OpenTelemetry project.
+- **"Plus":** These distributions provide added functionalities on top of
+  upstream through additional components. Examples include instrumentation
+  libraries or vendor exporters not upstreamed to the OpenTelemetry project.
+- **"Minus":** These distributions provide a subset of functionality from
+  upstream. Examples of this include the removal of instrumentation libraries or
+  receivers, processors, exporters, or extensions found in the OpenTelemetry
+  Collector project. These distributions may be provided to increase
+  supportability and security considerations.
+
+## Who can create a distribution?
+
+Anyone can create a distribution. Today, several [vendors](/ecosystem/vendors/)
+offer [distributions](/ecosystem/distributions/). In addition, end-users can
+consider creating a distribution if they want to use components in the
+[Registry](/ecosystem/registry/) that are not upstreamed to the OpenTelemetry
+project.
 
 ## Contribution or distribution?
 
@@ -63,7 +62,7 @@ implementations:
 - Can your scripts for "ease of use" be generalized?
 - Can your changes to default settings be the better option for everyone?
 - Are your additional packaging options really specific?
-- Might your test, performance & security coverage work with the reference
+- Might your test, performance and security coverage work with the reference
   implementation as well?
 - Have you checked with the community if your additional capabilities could be
   part of the standard?
@@ -79,14 +78,14 @@ If you are building your own distribution, the
 [OpenTelemetry Collector Builder](https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder)
 might be a good starting point.
 
-### Language Specific Instrumentation libraries
+### Language specific instrumentation libraries
 
 There are language specific extensibility mechanisms to customize the
 instrumentation libraries:
 
 - [Java agent](/docs/zero-code/java/agent/extensions)
 
-## What you should know about distributions
+## Follow the guidelines
 
 When using OpenTelemetry project collateral such as logo and name for your
 distribution, make sure that you are in line with the [OpenTelemetry Marketing