diff --git a/.github/workflows/checks.yaml b/.github/workflows/checks.yaml
index caf51cd9d2b..7495f15de64 100644
--- a/.github/workflows/checks.yaml
+++ b/.github/workflows/checks.yaml
@@ -91,3 +91,15 @@ jobs:
         config: .cspell.yaml
         suggestions: true
         treat_flagged_words_as_errors: true
+
+  textlint:
+    runs-on: ubuntu-latest
+    steps:
+    - name: check out code
+      uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5.0.1
+
+    - name: install dependencies
+      run: npm install
+
+    - name: run textlint
+      run: make textlint format=github
diff --git a/.textlintignore b/.textlintignore
new file mode 100644
index 00000000000..ea5265d9e22
--- /dev/null
+++ b/.textlintignore
@@ -0,0 +1,4 @@
+.textlintrc.yml
+.cspell/*
+.github/**
+spec-compliance-matrix.md
diff --git a/.textlintrc.yml b/.textlintrc.yml
new file mode 100644
index 00000000000..00f75576abe
--- /dev/null
+++ b/.textlintrc.yml
@@ -0,0 +1,188 @@
+# cspell:ignore ebpf matic postgres protable
+plugins:
+filters:
+  allowlist:
+    allow:
+      # Don't check registry .yml file fields for language, repo,URL and tags:
+      - '/^\s*(?:language|repo|name|docs|url|website): .*$/m'
+      - /^(?:tags):(\s*-.+$)*/m
+      # Hugo template syntax:
+      - /{{.*?}}/
+      - /{{%.*?%}}/
+      # Custom header anchors in markdown headings:
+      - /{#.*?}/
+      # src attribute in figure Hugo template:
+      - /src=".*?"/
+      # Other:
+      - /<https?:\/\/.*?>/ # Raw URLs
+      - /\[.+\/\w+\]/ # Paths in square brackets to look like URLs
+rules:
+  common-misspellings:
+    # Misspellings to be ignored (case-insensitive)
+    ignore: []
+  period-in-header: true
+  terminology:
+    defaultTerms: true
+    skip: []
+    exclude:
+      - 'bug[- ]fix(es)?'
+      - 'readme(s)?'
+      - 'to-?do(s)?(?=[ ,.])'
+      - "indexes\\b"
+    terms:
+      - Actix
+      - Ajax
+      - Apache
+      - API
+      - application/json
+      - AWS
+      - Azure
+      - Caml
+      - Cassandra
+      - Clojure
+      - CNCF
+      - eBPF
+      - ECMAScript
+      - Elixir
+      - Erlang
+      - GCP
+      - GitHub
+      - Gitpod
+      - GraphQL
+      - gRPC
+      - Haskell
+      - HTTP
+      - HTTPS
+      - ID
+      - iOS
+      - Istio
+      - Jaeger
+      - JavaScript
+      - JBoss
+      - Jetty
+      - JMX
+      - JSON
+      - Julia
+      - K8s
+      - Kafka
+      - KubeCon
+      - Kubernetes
+      - Laravel
+      - MacBook
+      - macOS
+      - Markdown
+      - MongoDB
+      - mTLS
+      - MySQL
+      - NDJSON
+      - Netlify
+      - NGINX
+      - OCaml
+      - OK
+      - OpAMP
+      - OpenSearch
+      - OpenTelemetry Collector
+      - OTel
+      - OTEP
+      - PDF
+      - Phoenix
+      - PHP
+      - PostgreSQL
+      - protobuf
+      - Python
+      - Quarkus
+      - Rails
+      - README
+      - Redis
+      - Ruby
+      - Rust
+      - SDK
+      - SemVer
+      - SQL
+      - SQLite
+      - Swift
+      - Symfony
+      - Thanos
+      - Traefik
+      - TypeScript
+      - UNIX
+      - URL
+      - WordPress
+      - WSGI
+      - YouTube
+      - Zend
+      - Zipkin
+      #
+      # ADVANCED RULES given as `[pattern, replacement]`, take as arguments to a
+      # search-and-replace of the form /pattern/replacement/.
+      #
+      # If the regex pattern starts with `(?<` or `(?=` or `(?!`, the
+      # terminology linter rule will use the regex AS IS to match strings in
+      # checked files. Otherwise, the pattern is wrapped into a regex with other
+      # constraints, such as requiring that is be at word boundaries. For
+      # details, see
+      # https://github.com/sapegin/textlint-rule-terminology/blob/ca36a645c56d21f27cb9d902b5fb9584030c59e3/index.js#L137-L142.
+      #
+      - ['3rd[- ]party', third-party]
+      - ['auto[- ]c(onfigur)(es?|ations?)', 'autoc$1$2'] # cSpell:disable-line
+      - ['back[- ]end(s)?', 'backend$1']
+      - ['bugfix(es?)', 'bug fix$1']
+      - [byte code, bytecode]
+      - ['(cloud)-(native)', '$1 $2']
+      - [cpp, C++]
+      - # dotnet|.net -> .NET, but NOT for strings like:
+        # - File extension: file.net
+        # - Repo names: opentelemetry-dotnet
+        # - Compound names: System.Net.Http.HttpClient
+        - '(?<=(^|\s))(?:\bdot|\.)net\b'
+        - .NET
+      - [ebpf, eBPF]
+      - [epbf, eBPF]
+      - ['http[ /]?2(?:\.0)?', HTTP/2]
+      - [he(/| or )she, they]
+      - [\(s\)he, they]
+      - ["indices\\b", "indexes"]
+      - ["id['’]?s", IDs]
+      - # Capitalize Java, but NOT for strings like:
+        # - File names: file.java
+        # - Repo names: opentelemetry-java
+        # - Compound names: java.util.List
+        - '(?<![.-])java\b(?![.])'
+        - Java
+      - ['java[- ]?agent', Java agent]
+      - ['java ?doc(s)?', 'Javadoc$1']
+      - ['mac ?os', macOS]
+      - ['meta[- ]data', metadata]
+      - ['nd-?json', NDJSON]
+      - ['node\.?js', Node.js]
+      - [open-source, open source]
+      - # OpenTelemetry
+        # Catch typos like: OpenTelemtry, opentelementry
+        # Exclude occurrences like:
+        # - Compound names: go.opentelemetry.io
+        # - Paths: medium.com/opentelemetry
+        # - Repo names: opentelemetry-cpp or ocaml-opentelemetry
+        # - Repo names: open-telemetry/opentelemetry-cpp
+        # - Slack or social media anchors: #opentelemetry or @opentelemetry
+        # cSpell:ignore teleme
+        - '(?<![-#@./])\bopen[- ]?teleme?n?try\b(?![-./])'
+        - OpenTelemetry
+      - [os x, macOS]
+      - [protable, portable]
+      - [postgres, PostgreSQL]
+      - ['psr[ -]?([0-9]+)', PSR-$1]
+      - ['react[ .]js', React]
+      - ['regexp?(s)?', regular expression$1]
+      - [repo\b, repository]
+      - [repos, repositories]
+      - ['screen[- ]shot(s)?', screenshot$1]
+      - ['time[- ]stamp(s)?', timestamp$1]
+      - ["to-?do(s)?", "TODO$1"]
+      - ["uid['’]?(s)?", UID$1]
+      - ['(walk)-(throughs?)', $1$2] # cSpell:disable-line
+      - ['(work)-(arounds?)', $1$2]
+      # Enable the following to find and replace "instrumentation module/package" with "instrumentation library":
+      # - ["(auto(matic)?[- ])?instrumentation (module|package)", "instrumentation library"]
+      # - ["(auto(matic)?[- ])?instrumentation (modules|packages)", "instrumentation libraries"]
+      - snake_case
+      - location_indices
diff --git a/.vscode/extensions.json b/.vscode/extensions.json
index 25b4eeb0e9a..d2fee10f32f 100644
--- a/.vscode/extensions.json
+++ b/.vscode/extensions.json
@@ -1,5 +1,6 @@
 {
     "recommendations": [
+        "3w36zj6.textlint",
         "streetsidesoftware.code-spell-checker",
         "streetsidesoftware.code-spell-checker-cspell-bundled-dictionaries"
     ]
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 86ad6dbce2a..f5f2d3f5bfc 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -628,7 +628,7 @@ release.
   ([#4203](https://github.com/open-telemetry/opentelemetry-specification/pull/4203))
   ([#4221](https://github.com/open-telemetry/opentelemetry-specification/pull/4221))
 - Introduce initial placeholder for the new user-facing Logs API, adding references
-  to existing API's informing of the coming changes while the definition is defined.
+  to existing APIs informing of the coming changes while the definition is defined.
   ([#4236](https://github.com/open-telemetry/opentelemetry-specification/pull/4236))
 
 ### Common
@@ -829,7 +829,7 @@ release.
   ([#4001](https://github.com/open-telemetry/opentelemetry-specification/pull/4001))
 - Error out on invalid identifiers in environment variable substitution.
   ([#4002](https://github.com/open-telemetry/opentelemetry-specification/pull/4002))
-- Add end to end examples for file configuration
+- Add end-to-end examples for file configuration
   ([#4018](https://github.com/open-telemetry/opentelemetry-specification/pull/4018))
 - Clarify the schema for YAML configuration files
   ([#3973](https://github.com/open-telemetry/opentelemetry-specification/pull/3973))
@@ -887,7 +887,7 @@ release.
   ([#3945](https://github.com/open-telemetry/opentelemetry-specification/pull/3945))
 - Prometheus: represent Prometheus Info, StateSet and Unknown-typed metrics in OTLP.
   ([#3868](https://github.com/open-telemetry/opentelemetry-specification/pull/3868))
-- Update and reorganize the Prometheus sdk exporter specification.
+- Update and reorganize the Prometheus SDK exporter specification.
   ([#3872](https://github.com/open-telemetry/opentelemetry-specification/pull/3872))
 
 ### SDK Configuration
@@ -1038,7 +1038,7 @@ release.
 
 ### Traces
 
-- Update OpenTelemetry to Zipkin Transformation to handle attributes from older semantic conventions in a backwards compatible way.
+- Update OpenTelemetry to Zipkin Transformation to handle attributes from older semantic conventions in a backward compatible way.
   ([#3794](https://github.com/open-telemetry/opentelemetry-specification/pull/3794))
 
 ### Metrics
@@ -1196,7 +1196,7 @@ release.
 
 ### Logs
 
-- Update two apache access logs mappings.
+- Update two Apache access logs mappings.
   ([#3712](https://github.com/open-telemetry/opentelemetry-specification/pull/3712))
 
 ### Resource
@@ -1566,9 +1566,9 @@ release.
 
 ### Logs
 
-- Update log readme "request context" to "trace context".
+- Update log README "request context" to "trace context".
   ([#3332](https://github.com/open-telemetry/opentelemetry-specification/pull/3332))
-- Remove log readme document status.
+- Remove log README document status.
   ([#3334](https://github.com/open-telemetry/opentelemetry-specification/pull/3334))
 - Break out compatibility document on recording trace context in non-OTLP Log Format
   ([#3331](https://github.com/open-telemetry/opentelemetry-specification/pull/3331))
@@ -1691,7 +1691,7 @@ release.
   ([#3250](https://github.com/open-telemetry/opentelemetry-specification/pull/3250))
 - Mark the attribute naming guidelines in the specification as stable.
   ([#3220](https://github.com/open-telemetry/opentelemetry-specification/pull/3220))
-- Mark telemetry schema readme stable.
+- Mark telemetry schema README stable.
   ([#3221](https://github.com/open-telemetry/opentelemetry-specification/pull/3221))
 - Remove mention of `net.transport` from HTTP semantic conventions
   ([#3244](https://github.com/open-telemetry/opentelemetry-specification/pull/3244))
@@ -1766,10 +1766,10 @@ release.
 - Rename google openshift platform attribute from `google_cloud_openshift` to `gcp_openshift`
   to match the existing `cloud.provider` prefix.
   ([#3095](https://github.com/open-telemetry/opentelemetry-specification/pull/3095))
-- Changes http server span names from `{http.route}` to `{http.method} {http.route}`
+- Changes HTTP server span names from `{http.route}` to `{http.method} {http.route}`
   (when route is available), and from `HTTP {http.method}` to `{http.method}` (when
   route is not available).
-  Changes http client span names from `HTTP {http.method}` to `{http.method}`.
+  Changes HTTP client span names from `HTTP {http.method}` to `{http.method}`.
   ([#3165](https://github.com/open-telemetry/opentelemetry-specification/pull/3165))
 - Mark `http.server.duration` and `http.client.duration` metrics as required, and mark
   all other HTTP metrics as optional.
@@ -1819,7 +1819,7 @@ release.
 
 - Clarify that the BatchSpanProcessor should export batches when the queue reaches the batch size
   ([#3024](https://github.com/open-telemetry/opentelemetry-specification/pull/3024))
-- Deprecate jaeger exporter, scheduled for spec removal in July 2023.
+- Deprecate Jaeger exporter, scheduled for spec removal in July 2023.
   [#2858](https://github.com/open-telemetry/opentelemetry-specification/pull/2858)
 
 ### Metrics
@@ -2026,7 +2026,7 @@ release.
   ([#2874](https://github.com/open-telemetry/opentelemetry-specification/pull/2874))
 - Add `process.paging.faults` metric to semantic conventions
   ([#2827](https://github.com/open-telemetry/opentelemetry-specification/pull/2827))
-- Define semantic conventions yaml for Non-OTLP conventions
+- Define semantic conventions YAML for Non-OTLP conventions
   ([#2850](https://github.com/open-telemetry/opentelemetry-specification/pull/2850))
 - Add more semantic convetion attributes of Apache RocketMQ
   ([#2881](https://github.com/open-telemetry/opentelemetry-specification/pull/2881))
@@ -2095,7 +2095,7 @@ release.
   ([#2819](https://github.com/open-telemetry/opentelemetry-specification/pull/2819))
 - Make context propagation requirements explicit for messaging semantic conventions
   ([#2750](https://github.com/open-telemetry/opentelemetry-specification/pull/2750)).
-- Update http metrics to use `http.route` instead of `http.target` for servers,
+- Update HTTP metrics to use `http.route` instead of `http.target` for servers,
   drop `http.url` for clients
   ([#2818](https://github.com/open-telemetry/opentelemetry-specification/pull/2818)).
 
@@ -2197,7 +2197,7 @@ release.
 - Add `rpc.grpc.status_code` to RPC metric semantic conventions
   ([#2604](https://github.com/open-telemetry/opentelemetry-specification/pull/2604))
 - Add `http.*.*.size` metric semantic conventions for tracking size of requests
-  / responses for http servers / clients
+  / responses for HTTP servers / clients
   ([#2588](https://github.com/open-telemetry/opentelemetry-specification/pull/2588))
 - BREAKING: rename `net.peer.ip` to `net.sock.peer.addr`, `net.host.ip` to `net.sock.host.addr`,
   `net.peer.name` to `net.sock.peer.name` for socket-level instrumentation.
@@ -2207,7 +2207,7 @@ release.
   ([#2650](https://github.com/open-telemetry/opentelemetry-specification/pull/2650))
 - Improve the definition of `state` attribute for metric `system.network.connections`
   ([#2663](https://github.com/open-telemetry/opentelemetry-specification/pull/2663))
-- Add `process.parent_pid` attribute for use in reporting parent process id (PID)
+- Add `process.parent_pid` attribute for use in reporting parent process ID (PID)
   ([#2691](https://github.com/open-telemetry/opentelemetry-specification/pull/2691))
 - Add OpenSearch to db.system semantic conventions
   ([#2718](https://github.com/open-telemetry/opentelemetry-specification/pull/2718))
@@ -2294,7 +2294,7 @@ release.
   ([#2536](https://github.com/open-telemetry/opentelemetry-specification/pull/2536))
 - Add database connection pool metrics semantic conventions
   ([#2273](https://github.com/open-telemetry/opentelemetry-specification/pull/2273)).
-- Specify how to obtain a Ruby thread's id
+- Specify how to obtain a Ruby thread's ID
   ([#2508](https://github.com/open-telemetry/opentelemetry-specification/pull/2508)).
 - Refactor jvm classes semantic conventions
   ([#2550](https://github.com/open-telemetry/opentelemetry-specification/pull/2550)).
@@ -2364,8 +2364,8 @@ release.
 ### Semantic Conventions
 
 - Note added that `net.peer.name` SHOULD NOT be set if capturing it would require an
-  extra reverse DNS lookup. And moved `net.peer.name` from common http attributes to
-  just client http attributes.
+  extra reverse DNS lookup. And moved `net.peer.name` from common HTTP attributes to
+  just client HTTP attributes.
   ([#2446](https://github.com/open-telemetry/opentelemetry-specification/pull/2446))
 - Add `net.host.name` and `net.host.ip` conventions for rpc server spans.
   ([#2447](https://github.com/open-telemetry/opentelemetry-specification/pull/2447))
@@ -2604,7 +2604,7 @@ release.
   ([#2191](https://github.com/open-telemetry/opentelemetry-specification/pull/2191))
 - Add `device.manufacturer` to describe mobile device manufacturers.
   ([2100](https://github.com/open-telemetry/opentelemetry-specification/pull/2100))
-- Change golang namespace to 'go', rather than 'gc'
+- Change Go namespace to 'go', rather than 'gc'
   ([#2262](https://github.com/open-telemetry/opentelemetry-specification/pull/2262))
 - Add JVM memory runtime semantic
   conventions. ([#2272](https://github.com/open-telemetry/opentelemetry-specification/pull/2272))
@@ -2699,11 +2699,11 @@ release.
   ([#2004](https://github.com/open-telemetry/opentelemetry-specification/pull/2004))
 - Add Tencent Cloud as a cloud provider.
   ([#2006](https://github.com/open-telemetry/opentelemetry-specification/pull/2006))
-- Don't set Span.Status for 4xx http status codes for SERVER spans.
+- Don't set Span.Status for 4xx HTTP status codes for SERVER spans.
   ([#1998](https://github.com/open-telemetry/opentelemetry-specification/pull/1998))
 - Add attributes for Apache RocketMQ.
   ([#1904](https://github.com/open-telemetry/opentelemetry-specification/pull/1904))
-- Define http tracing attributes provided at span creation time
+- Define HTTP tracing attributes provided at span creation time
   ([#1916](https://github.com/open-telemetry/opentelemetry-specification/pull/1916))
 - Change meaning and discourage use of `faas.trigger` for FaaS clients (outgoing).
   ([#1921](https://github.com/open-telemetry/opentelemetry-specification/pull/1921))
@@ -2716,7 +2716,7 @@ release.
 
 ### OpenTelemetry Protocol
 
-- Clarify default for OTLP endpoint should, not must, be https
+- Clarify default for OTLP endpoint should, not must, be HTTPS
   ([#1997](https://github.com/open-telemetry/opentelemetry-specification/pull/1997))
 - Specify the behavior of the OTLP endpoint variables for OTLP/HTTP more strictly
   ([#1975](https://github.com/open-telemetry/opentelemetry-specification/pull/1975),
@@ -2782,7 +2782,7 @@ Added telemetry schemas documents to the specification ([#2008](https://github.c
 - Update YAML definitions for events
   ([#1843](https://github.com/open-telemetry/opentelemetry-specification/pull/1843)):
   - Mark exception as semconv type "event".
-  - Add YAML definitions for grpc events.
+  - Add YAML definitions for gRPC events.
 - Add `messaging.consumer_id` to differentiate between message consumers.
   ([#1810](https://github.com/open-telemetry/opentelemetry-specification/pull/1810))
 - Clarifications for `http.client_ip` and `http.host`.
@@ -2994,14 +2994,14 @@ Added telemetry schemas documents to the specification ([#2008](https://github.c
 
 ### Logs
 
-- Clarify "key/value pair list" vs "map" in Log Data Model. ([#1604](https://github.com/open-telemetry/opentelemetry-specification/pull/1604))
+- Clarify "key-value pair list" vs "map" in Log Data Model. ([#1604](https://github.com/open-telemetry/opentelemetry-specification/pull/1604))
 
 ### Semantic Conventions
 
 - Fix the inconsistent formatting of semantic convention enums. ([#1598](https://github.com/open-telemetry/opentelemetry-specification/pull/1598/))
 - Add details for filling resource for AWS Lambda. ([#1610](https://github.com/open-telemetry/opentelemetry-specification/pull/1610))
 - Add already specified `messaging.rabbitmq.routing_key` span attribute key to the respective YAML file. ([#1651](https://github.com/open-telemetry/opentelemetry-specification/pull/1651))
-- Clarify usage of "otel." attribute namespace. ([#1640](https://github.com/open-telemetry/opentelemetry-specification/pull/1640))
+- Clarify usage of `otel.*` attribute namespace. ([#1640](https://github.com/open-telemetry/opentelemetry-specification/pull/1640))
 - Add possibility to disable `db.statement` via instrumentation configuration. ([#1659](https://github.com/open-telemetry/opentelemetry-specification/pull/1659))
 
 ### Compatibility
@@ -3197,7 +3197,7 @@ New:
     [#946](https://github.com/open-telemetry/opentelemetry-specification/pull/946))
 - Allow samplers to modify tracestate
   ([#988](https://github.com/open-telemetry/opentelemetry-specification/pull/988/))
-- Update the header name for otel baggage, and version date
+- Update the header name for OTel baggage, and version date
   ([#981](https://github.com/open-telemetry/opentelemetry-specification/pull/981))
 - Define PropagationOnly Span to simplify active Span logic in Context
   ([#994](https://github.com/open-telemetry/opentelemetry-specification/pull/994))
@@ -3254,12 +3254,12 @@ Updates:
   ([#610](https://github.com/open-telemetry/opentelemetry-specification/pull/610))
 - Rename ProbabilitySampler to TraceIdRatioBasedSampler and add requirements
   ([#611](https://github.com/open-telemetry/opentelemetry-specification/pull/611))
-- Version attributes no longer have a prefix such as semver:
+- Version attributes no longer have a prefix such as SemVer:
   ([#873](https://github.com/open-telemetry/opentelemetry-specification/pull/873))
 - Add semantic conventions for process runtime
   ([#882](https://github.com/open-telemetry/opentelemetry-specification/pull/882),
    [#1137](https://github.com/open-telemetry/opentelemetry-specification/pull/1137))
-- Use hex encoding for trace id and span id fields in OTLP JSON encoding:
+- Use hex encoding for trace ID and span ID fields in OTLP JSON encoding:
   ([#911](https://github.com/open-telemetry/opentelemetry-specification/pull/911))
 - Explicitly specify the SpanContext APIs IsValid and IsRemote as required
   ([#914](https://github.com/open-telemetry/opentelemetry-specification/pull/914))
@@ -3305,7 +3305,7 @@ New:
   ([#650](https://github.com/open-telemetry/opentelemetry-specification/pull/650))
 - Add conventions for naming of exporter packages
   ([#629](https://github.com/open-telemetry/opentelemetry-specification/pull/629))
-- Add semantic conventions for container id
+- Add semantic conventions for container ID
   ([#673](https://github.com/open-telemetry/opentelemetry-specification/pull/673))
 - Add semantic conventions for HTTP content length
   ([#641](https://github.com/open-telemetry/opentelemetry-specification/pull/641))
@@ -3344,7 +3344,7 @@ Updates:
 - Update api-metrics-user.md and api-metrics-meter.md with the latest metrics
   API.
 - Normalize Instrumentation term for instrumentations.
-- Change w3c correlation context to custom header.
+- Change W3C correlation context to custom header.
 
 ## v0.4.0 (2020-05-12)
 
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 54e238e6eae..13041cd014a 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -19,7 +19,7 @@ Proposal](https://github.com/open-telemetry/oteps) process.
 Smaller changes can follow a shorter process:
 
 - [Create an issue](https://github.com/open-telemetry/opentelemetry-specification/issues/new/choose)
-  in this repo and describe the proposed change.
+  in this repository and describe the proposed change.
 - Follow the [issue workflow](#issue-triaging) and make sure the issue is accepted with
   a "Yes" response. If the response to the issue is not "Yes" then do not create a PR
   that implements the change since it will be rejected.
@@ -49,7 +49,7 @@ issue.
 
 ## Writing specs
 
-Specification is written in markdown format. Please make sure files are rendered
+Specification is written in Markdown format. Please make sure files are rendered
 correctly on GitHub.
 
 Be sure to clearly define the specification requirements using appropriate
@@ -104,7 +104,7 @@ checks directly.
 See:
 
 - [MarkdownStyle](#markdown-style)
-- [CSpell Check](#cspell-check)
+- [Text Correction](#text-correction)
 - Markdown link checking (docs TODO)
 
 ### Autoformatting
@@ -120,6 +120,7 @@ You can also run these fixes individually.
 
 See:
 
+- [Text Correction](#text-correction)
 - Table Generation (docs TODO)
 
 ### Markdown style
@@ -130,7 +131,7 @@ In this repository we follow the
 with some customizations. See [markdownlint](.markdownlint.yaml) or
 [settings](.vscode/settings.json) for details.
 
-We highly encourage to use line breaks in markdown files at `80` characters
+We highly encourage to use line breaks in Markdown files at `80` characters
 wide. There are tools that can do it for you effectively. Please submit proposal
 to include your editor settings required to enable this behavior so the out of
 the box settings for this repository will be consistent.
@@ -145,16 +146,22 @@ To fix style violations, follow the
 [instruction](https://github.com/DavidAnson/markdownlint#optionsresultversion)
 with the Node version of markdownlint. If you are using Visual Studio Code,
 you can also use the `fixAll` command of the
-[vscode markdownlint extension](https://github.com/DavidAnson/vscode-markdownlint).
+[Visual Studio Code markdownlint extension](https://github.com/DavidAnson/vscode-markdownlint).
 
-### CSpell check
+### Text Correction
 
 In addition, please make sure to clean up typos before you submit the change.
 
-To check for typos, run the following command:
+To check for typos (misspell) and style of writing (textlint), run the following command:
 
 ```bash
-make cspell
+make language-analysis
+```
+
+To quickly fix common misspellings and style, use
+
+```bash
+make textlint-correction
 ```
 
 ## Updating the Compliance Matrix
@@ -212,7 +219,7 @@ pull requests (PRs).
 
 To [create a new
 PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request),
-fork the project in GitHub and clone the upstream repo:
+fork the project in GitHub and clone the upstream repository:
 
 ```sh
 git clone https://github.com/open-telemetry/opentelemetry-specification.git
@@ -233,7 +240,7 @@ $ git commit
 $ git push fork feature
 ```
 
-Open a pull request against the main `opentelemetry-specification` repo.
+Open a pull request against the main `opentelemetry-specification` repository.
 
 If the PR is not ready for review, please mark it as
 [`draft`](https://github.blog/news-insights/product-news/introducing-draft-pull-requests/).
diff --git a/Makefile b/Makefile
index 813ef45d9e8..504bd6a9629 100644
--- a/Makefile
+++ b/Makefile
@@ -22,13 +22,32 @@ SEMCONVGEN_VERSION=0.17.0
 
 # TODO: add `yamllint` step to `all` after making sure it works on Mac.
 .PHONY: all
-all: install-tools markdownlint markdown-link-check cspell
+all: install-tools markdownlint textlint markdown-link-check cspell
 
+# Perform an analysis of language used which includes spell checking and linting.
+.PHONY: language-analysis
+language-analysis: textlint cspell
+ 
 .PHONY: cspell
 cspell:
 	@if ! npm ls cspell; then npm install; fi
 	npx cspell . --no-progress
 
+.PHONY: textlint
+textlint:
+	@if ! npm ls textlint; then npm install; fi
+
+	@if [ "$(format)" = "github" ]; then \
+		npx textlint --format github .; \
+	else \
+		npx textlint .; \
+	fi
+
+.PHONY: textlint-correction
+textlint-correction:
+	@if ! npm ls textlint; then npm install; fi
+	npx textlint --fix .
+
 .PHONY: markdown-link-check
 markdown-link-check:
 	docker run --rm \
@@ -92,9 +111,14 @@ yamllint:
 
 # Run all checks in order of speed / likely failure.
 .PHONY: check
-check: cspell markdownlint markdown-link-check
+check: cspell textlint markdownlint markdown-link-check
 	@echo "All checks complete"
 
+# Attempt to fix issues / regenerate tables.
+.PHONY: fix
+fix: textlint-correction
+	@echo "All autofixes complete"
+
 # Generate spec compliance matrix from YAML source
 .PHONY: compliance-matrix
 compliance-matrix: check-python
diff --git a/README.md b/README.md
index a3d40ec503f..76490b54517 100644
--- a/README.md
+++ b/README.md
@@ -29,7 +29,7 @@ APAC timezone friendly meetings are held on request. See
 [OpenTelemetry calendar](https://github.com/open-telemetry/community#calendar).
 
 Escalations to technical committee may be made over the
-[e-mail](https://github.com/open-telemetry/community/blob/main/README.md#mailing-lists).
+[email](https://github.com/open-telemetry/community/blob/main/README.md#mailing-lists).
 Technical committee holds regular meetings, notes are held
 [here](https://docs.google.com/document/d/1hOHPCu5TGenqTeWPB9qQB_qd33uITZBcvK1FnWxYJAw/edit?usp=sharing).
 
diff --git a/development/metrics/config-service.md b/development/metrics/config-service.md
index 11884815943..6559e87d623 100644
--- a/development/metrics/config-service.md
+++ b/development/metrics/config-service.md
@@ -158,7 +158,7 @@ duration, even if they violate the divisibility suggestion.
 ### Go SDK
 
 A prototype implementation of metric configuration is available for the Go SDK,
-currently hosted on the [contrib repo](https://github.com/vmingchen/opentelemetry-go-contrib). It provides an
+currently hosted on the [contrib repository](https://github.com/vmingchen/opentelemetry-go-contrib). It provides an
 alternative push controller component with the ability to configure collection
 periods on a per-metric basis. When used in conjunction with the Collector
 extension (see below), the controller exports metrics based on configuration
@@ -176,7 +176,7 @@ this feature.
 ### Collector Extension
 
 An example configuration backend is implemented as an extension for the
-Collector, currently hosted on the [contrib repo](https://github.com/vmingchen/opentelemetry-collector-contrib). When this extension is enabled, the Collector
+Collector, currently hosted on the [contrib repository](https://github.com/vmingchen/opentelemetry-collector-contrib). When this extension is enabled, the Collector
 functions as a potential endpoint for Agent/SDKs to retrieve configuration data.
 The following schematic illustrates the Collector’s position in the overall
 architecture, as well as how the configuration information flows.
diff --git a/development/trace/zpages.md b/development/trace/zpages.md
index c72b5329fb9..3eed2de534a 100644
--- a/development/trace/zpages.md
+++ b/development/trace/zpages.md
@@ -87,9 +87,9 @@ Each zPages implementation MUST create a wrapper class for zPages, since they al
 
 ### HTTP Server
 
-All zPages MUST have a HTTP Server to render information on a webpage when a host:port and endpoint is accessed. All zPages MUST be accessed from the same host:port; For example, host1 should equal host2 and port1 should equal port2 for `host1:post1/tracez` and `host2:port2/rpcz`. There SHOULD be handlers to group logic by type of zPage, and there SHOULD be a landing page. This landing page would be at the root `host:port/`, displaying links to currently implemented zPages for that repository. Similar behavior MAY be implemented for any invalid endpoints as well.
+All zPages MUST have a HTTP Server to render information on a web page when a host:port and endpoint is accessed. All zPages MUST be accessed from the same host:port; For example, host1 should equal host2 and port1 should equal port2 for `host1:post1/tracez` and `host2:port2/rpcz`. There SHOULD be handlers to group logic by type of zPage, and there SHOULD be a landing page. This landing page would be at the root `host:port/`, displaying links to currently implemented zPages for that repository. Similar behavior MAY be implemented for any invalid endpoints as well.
 
-Traditionally, zPages have approached this by rendering web pages purely on the server-side. This means the server would only serve static resources (HTML, CSS and possibly Javascript) when the user accesses a given endpoint. Based on the type of zPage and the server language used, a pure server-side approach would generate HTML pages using hardcoded strings from scratch or using a template; this would tightly couple the data and UI layer.
+Traditionally, zPages have approached this by rendering web pages purely on the server-side. This means the server would only serve static resources (HTML, CSS and possibly JavaScript) when the user accesses a given endpoint. Based on the type of zPage and the server language used, a pure server-side approach would generate HTML pages using hardcoded strings from scratch or using a template; this would tightly couple the data and UI layer.
 
 The following endpoints SHOULD be used for serving files (which are ideally standardized, per the [Shared Static Files](#shared-static-files) sections under future possibilities), for any HTTP server approach for any zPage:
 
@@ -99,11 +99,11 @@ The following endpoints SHOULD be used for serving files (which are ideally stan
   - `host:port/{zpage}/{...}`, and other variants SHOULD display detailed information on the data described by the {...}
     - an example of this: If a user accesses `host:port/tracez?type=error&name=span1`, that Tracez page should display all currently sampled error spans with the name `span1`
 - If adding client-side:
-  - `host:port/{zpage}/script.js` SHOULD return the frontend Javascript code if these zPages uses client-side interaction. This MAY also be embedded in the HTML, but SHOULD be separated and linked in the page head using `<script src="/{zpage}/script.js">`
+  - `host:port/{zpage}/script.js` SHOULD return the frontend JavaScript code if these zPages uses client-side interaction. This MAY also be embedded in the HTML, but SHOULD be separated and linked in the page head using `<script src="/{zpage}/script.js">`
 
-All zPages need some server-side rendering, but the data and UI layer MAY be separated by adding client-side functionality. This separation has benefits including 1.) allowing users to consume zPages data without a browser, styling, or Javascript, such as when using wget on the endpoints serving JSON data and 2.) adding extensibility to zPages (e.g. the frontend can be centralized and used in multiple  OTel language repositories). This approach is detailed below.
+All zPages need some server-side rendering, but the data and UI layer MAY be separated by adding client-side functionality. This separation has benefits including 1.) allowing users to consume zPages data without a browser, styling, or JavaScript, such as when using wget on the endpoints serving JSON data and 2.) adding extensibility to zPages (e.g. the frontend can be centralized and used in multiple  OTel language repositories). This approach is detailed below.
 
-Instead of directly translating native data structures to HTML strings based on the stored information, the data layer MUST do 2 things depending on the webpage endpoint accessed: 1. Serve the static HTML, JS, and CSS files, which are not not data dependent and 2. Act like a web REST API by translating stored data to JSON. Whether the data layer does one or the other depends on which URL endpoint is accessed; the former is intended for the initial zPages load, and latter for user interactions. If the client requests the data via a request parameter or "Accept" HTTP header, that data should be available as a JSON-encoded response.
+Instead of directly translating native data structures to HTML strings based on the stored information, the data layer MUST do 2 things depending on the web page endpoint accessed: 1. Serve the static HTML, JS, and CSS files, which are not not data dependent and 2. Act like a web REST API by translating stored data to JSON. Whether the data layer does one or the other depends on which URL endpoint is accessed; the former is intended for the initial zPages load, and latter for user interactions. If the client requests the data via a request parameter or "Accept" HTTP header, that data should be available as a JSON-encoded response.
 
 If using the server/client approach for the HTTP server, the following endpoints and data formatting (using proto3 definitions) SHOULD be used for serving JSON:
 
@@ -167,7 +167,7 @@ If using the server/client approach for the HTTP server, the following endpoints
 
 > TODO: add more zPage endpoint specs (i.e. URL and data formatting, required/optional parameters) and additional review of fields desired as we likely want many/all of the OTLP fields (e.g. SpanKind)
 
-The UI/frontend/rendering layer is the HTML, CSS, and Javascript itself, in contrast to the logic to serve those files. This frontend uses the data layer's API on the client-side within the browser with Javascript by accessing certain endpoints depending on the user's actions. The data returned interacts with the Javascript, which determines and executes the logic necessary to render updates to the HTML DOM. Modifying the HTML DOM means there are no unnecessary requesting and re-rendering static files, and only parts of the webpage are changed. This makes subsequent data queries quicker and requires no knowledge of client-side rendering for the zPages developer.
+The UI/frontend/rendering layer is the HTML, CSS, and JavaScript itself, in contrast to the logic to serve those files. This frontend uses the data layer's API on the client-side within the browser with JavaScript by accessing certain endpoints depending on the user's actions. The data returned interacts with the JavaScript, which determines and executes the logic necessary to render updates to the HTML DOM. Modifying the HTML DOM means there are no unnecessary requesting and re-rendering static files, and only parts of the web page are changed. This makes subsequent data queries quicker and requires no knowledge of client-side rendering for the zPages developer.
 
 In either case, a benefit of reasoning about the zPages HTTP server as a separate component means that zPages can be mounted in an existing server. For example, this can be done in Java by calling zPages logic from a servlet. It's also worth noting that having zPages in an embedded HTTP server increases the vulnerability of application and security risks by increasing its attack surface area. A malicious actor could potentially read sensitive data in telemetry, perform DOS attacks on the HTTP server, or initiate a telemetry storm by reconfiguring how telemetry is collected (i.e. through TraceConfigz); zPages should be reserved for protected dev environments for most cases because of this.
 
@@ -177,7 +177,7 @@ In either case, a benefit of reasoning about the zPages HTTP server as a separat
 
 ### Shared Static Files
 
-All HTML, CSS, and Javascript files would be used across different OTel language repositories for their in-process zPages
+All HTML, CSS, and JavaScript files would be used across different OTel language repositories for their in-process zPages
 
 - Pros
   - When client-side features are rolled out (including filtering/sorting data, interval refreshing, unit toggles), changes are all centralized
@@ -186,7 +186,7 @@ All HTML, CSS, and Javascript files would be used across different OTel language
 - Cons
   - Adds computation of converting native data structures into JSON strings and serving these static files. May need extra libraries
   - Some process has to be created to update the static files in a repository and serving them at the correct endpoints
-  - Initial setup may be difficult (one way this can be achieved is with Github modules)
+  - Initial setup may be difficult (one way this can be achieved is with GitHub modules)
 
 ### Out-process
 
diff --git a/issue-management.md b/issue-management.md
index 5ce312f3a1b..0ffaa6f1aa8 100644
--- a/issue-management.md
+++ b/issue-management.md
@@ -64,7 +64,7 @@ Rejected issues are issues that describe a problem that cannot or will not be so
 
 ## SIG Specific Issues
 
-Many SIGs track work in the specification repo that is outside of the triage process listed above.
+Many SIGs track work in the specification repository that is outside of the triage process listed above.
 These issues, which may be created by a SIG or just assigned to them, should be added to the SIG's project board and given the label `sig-issue`.
 If an issue is labeled as a `sig-issue`, it is the responsibility of the SIG to prioritize
 the issue appropriately, and ensure it is completed or closed as won't fix.
@@ -76,10 +76,10 @@ that block their implementation, or they may want to request a specification cha
 highlight issues of that kind SIG maintainers can request a `maintainer-request` label being added
 to an issue, if the following conditions are met:
 
-* the issue description or a comment by the maintainer points to at least one issue in an implementation repo, of which they are a maintainer.
+* the issue description or a comment by the maintainer points to at least one issue in an implementation repository, of which they are a maintainer.
 * the maintainer summarizes in the issue description or in a comment to an existing issue, what is blocking them and/or what is required from their point of view to make progress.
-* the maintainer tags all other maintainers of the implementation repo in the issue description or their comment (@open-telemetry/<sig>-maintainers). No action from the other maintainers is expected, except they disagree with
+* the maintainer tags all other maintainers of the implementation repository in the issue description or their comment (@open-telemetry/<sig>-maintainers). No action from the other maintainers is expected, except they disagree with
   the request of this issue being tagged as `maintainer-request`.
-* they will share the issue with all other SIGs either via the [Maintainer Meeting](https://github.com/open-telemetry/community?tab=readme-ov-file#cross-cutting-sigs) or via a message to [#otel-maintainers](https://cloud-native.slack.com/archives/C01NJ7V1KRC) on [CNCF slack](https://slack.cncf.io). This way maintainers of other implementation SIGs can comment if they have the same request.
+* they will share the issue with all other SIGs either via the [Maintainer Meeting](https://github.com/open-telemetry/community?tab=readme-ov-file#cross-cutting-sigs) or via a message to [#otel-maintainers](https://cloud-native.slack.com/archives/C01NJ7V1KRC) on [CNCF Slack](https://slack.cncf.io). This way maintainers of other implementation SIGs can comment if they have the same request.
 
 A triager will add the `maintainer-request` label to the issue if those conditions are met.
diff --git a/oteps/0001-telemetry-without-manual-instrumentation.md b/oteps/0001-telemetry-without-manual-instrumentation.md
index 61999a80331..6fe4cf03e45 100644
--- a/oteps/0001-telemetry-without-manual-instrumentation.md
+++ b/oteps/0001-telemetry-without-manual-instrumentation.md
@@ -4,7 +4,7 @@ _Cross-language requirements for automated approaches to extracting portable tel
 
 ## Motivation
 
-The purpose of OpenTelemetry is to make robust, portable telemetry a built-in feature of cloud-native software. For some software and some situations, that instrumentation can literally be part of the source code. In other situations, it’s not so simple: for example, we can’t necessarily edit or even recompile some of our software, the OpenTelemetry instrumentation only exists as a plugin, or instrumentation just never rises to the top of the priority list for a service-owner. Furthermore, there is occasionally a desire to disable instrumentation for a single plugin or module at runtime, again without requiring developers to make changes to source code.
+The purpose of OpenTelemetry is to make robust, portable telemetry a built-in feature of cloud native software. For some software and some situations, that instrumentation can literally be part of the source code. In other situations, it’s not so simple: for example, we can’t necessarily edit or even recompile some of our software, the OpenTelemetry instrumentation only exists as a plugin, or instrumentation just never rises to the top of the priority list for a service-owner. Furthermore, there is occasionally a desire to disable instrumentation for a single plugin or module at runtime, again without requiring developers to make changes to source code.
 
 One way to navigate situations like these is with a software layer that adds OpenTelemetry instrumentation to a service without modifying the source code for that service. (In the conventional APM world, these software layers are often called “agents”, though that term is overloaded and ambiguous so we try avoid it in this document.)
 
@@ -36,12 +36,12 @@ Without further ado, here are a set of requirements for “official” OpenTelem
 * The code in the OpenTelemetry package must not take a hard dependency on any particular vendor/vendors (that sort of functionality should work via a plugin or registry mechanism)
   * Further, the code in the OpenTelemetry package must be isolated to avoid possible conflicts with the host application (e.g., shading in Java, etc)
 
-### Nice-to-have properties
+### Nice to have properties
 
-* Run-time integration (vs compile-time integration)
+* Runtime integration (vs compile-time integration)
 * Automated and modular testing of individual library/package plugins
   * Note that this also makes it easy to test against multiple different versions of any given library
-* A fully pluggable architecture, where plugins can be registered at runtime without requiring changes to the central repo at github.com/open-telemetry
+* A fully pluggable architecture, where plugins can be registered at runtime without requiring changes to the central repository at github.com/open-telemetry
   * E.g., for ops teams that want to write a plugin for a proprietary piece of legacy software they are unable to recompile
 * Augmentation of whitebox instrumentation by blackbox instrumentation (or, perhaps, vice versa). That is, not only can the trace context be shared by these different flavors of instrumentation, but even things like in-flight Span objects can be shared and co-modified (e.g., to use runtime interposition to grab local variables and attach them to a manually-instrumented span).
 
@@ -53,12 +53,12 @@ There is also a school of thought that we should only be focusing on the bits an
 
 ## Proposal
 
-### What is our desired end state for OpenTelemetry end-users?
+### What is our desired end state for OpenTelemetry end users?
 
 To reiterate much of the above:
 
 * First and foremost, **portable OpenTelemetry instrumentation can be installed without manual source code modification**
-* There’s one “clear winner” when it comes to portable, automatic instrumentation; just like with OpenTracing and OpenCensus, this is a situation where choice is not necessarily a good thing. End-users who wish to contribute instrumentation plugins should not have their enthusiasm and generosity diluted across competing projects.
+* There’s one “clear winner” when it comes to portable, automatic instrumentation; just like with OpenTracing and OpenCensus, this is a situation where choice is not necessarily a good thing. End users who wish to contribute instrumentation plugins should not have their enthusiasm and generosity diluted across competing projects.
 * As much as such a thing is possible, consistency across languages
 * Broad coverage / “plugin support”
 * Broad vendor support for OpenTelemetry
@@ -72,18 +72,18 @@ Given the desired end state, the Datadog tracers seem like the closest-fit, perm
 
 * Start with [the Datadog `dd-trace-foo` tracers](https://github.com/DataDog)
 * For each language:
-  * Fork the Datadog `datadog/dd-trace-foo` repo into a `open-telemetry/auto-instr-foo` OpenTelemetry repo (exact naming TBD)
+  * Fork the Datadog `datadog/dd-trace-foo` repository into a `open-telemetry/auto-instr-foo` OpenTelemetry repository (exact naming TBD)
   * In parallel:
     * The `dd-trace-foo` codebases already do a good job separating Datadog-specific functionality from general-purpose functionality. Where needed, make that boundary even more explicit through an API (or "SPI", really).
     * Create a new `dd-trace-foo` lib that wraps `auto-instr-foo` and includes the Datadog-specific pieces factored out above
     * Show that it’s also possible to bind to arbitrary OpenTelemetry-based tracers to the above API/SPI
   * Declare the forked `auto-instr-foo` repository ready for production beta use
   * For some (ideally brief) period:
-    * When new plugins are added to Datadog's (original) repo, merge them over into the `auto-instr-foo` repo
-    * Allow Datadog end-users to bind to either for some period of time (ultimately Datadog's decision on timeline here, and does not prevent other tracers from using `auto-instr-foo`)
+    * When new plugins are added to Datadog's (original) repository, merge them over into the `auto-instr-foo` repository
+    * Allow Datadog end users to bind to either for some period of time (ultimately Datadog's decision on timeline here, and does not prevent other tracers from using `auto-instr-foo`)
     * Finally, when the combination of `auto-instr-foo` and a Datadog wrapper is functionally equivalent to the `dd-trace-foo` mainline, the latter can be safely replaced by the former.
-      * Note that, by design, this is not expected to affect Datadog end-users
-  * Moved repo is GA’d: all new plugins (and improvements to the auto-instrumentation core) happen in the `auto-instr-foo` repo
+      * Note that, by design, this is not expected to affect Datadog end users
+  * Moved repository is GA’d: all new plugins (and improvements to the auto-instrumentation core) happen in the `auto-instr-foo` repository
 
 There are some languages that will have OpenTelemetry support before they have Datadog `dd-trace-foo` support. In those situations, we will fall back to the requirements in this OTEP and leave the technical determinations up to the language SIG and the OpenTelemetry TC.
 
diff --git a/oteps/0016-named-tracers.md b/oteps/0016-named-tracers.md
index ee3dcd168f0..e7e36080b62 100644
--- a/oteps/0016-named-tracers.md
+++ b/oteps/0016-named-tracers.md
@@ -31,7 +31,7 @@ This proposal attempts to solve the stated problems by introducing the concept o
 * _Named Tracers and Meters_ which are associated with the **name** (e.g. _"io.opentelemetry.contrib.mongodb"_) and **version** (e.g._"semver:1.0.0"_) of the library which acquired them.
 * A `TracerProvider` / `MeterProvider` as the only means of acquiring a Tracer or Meter.
 
-Based on the name and version, a Provider could provide a no-op Tracer or Meter to specific instrumentation libraries, or a Sampler could be implemented that discards Spans or Metrics from certain libraries. Also, by providing custom Exporters, Span or Metric data could be sanitized before it gets processed in a back-end system. However, this is beyond the scope of this proposal, which only provides the fundamental mechanisms.
+Based on the name and version, a Provider could provide a no-op Tracer or Meter to specific instrumentation libraries, or a Sampler could be implemented that discards Spans or Metrics from certain libraries. Also, by providing custom Exporters, Span or Metric data could be sanitized before it gets processed in a backend system. However, this is beyond the scope of this proposal, which only provides the fundamental mechanisms.
 
 ## Explanation
 
@@ -50,7 +50,7 @@ Meter meter = OpenTelemetry.getMeterProvider().getMeter("io.opentelemetry.contri
 
 These factories (`TracerProvider` and `MeterProvider`) replace the global `Tracer` / `Meter` singleton objects as ubiquitous points to request Tracer and Meter instances.
 
- The _name_ used to create a Tracer or Meter must identify the _instrumentation_ libraries (also referred to as _integrations_) and not the library being instrumented. These instrumentation libraries could be libraries developed in an OpenTelemetry repository, a 3rd party implementation, or even auto-injected code (see [OpenTelemetry Without Manual Instrumentation OTEP](https://github.com/open-telemetry/oteps/blob/main/text/0001-telemetry-without-manual-instrumentation.md)). See also the examples for identifiers at the end.
+ The _name_ used to create a Tracer or Meter must identify the _instrumentation_ libraries (also referred to as _integrations_) and not the library being instrumented. These instrumentation libraries could be libraries developed in an OpenTelemetry repository, a third-party implementation, or even auto-injected code (see [OpenTelemetry Without Manual Instrumentation OTEP](https://github.com/open-telemetry/oteps/blob/main/text/0001-telemetry-without-manual-instrumentation.md)). See also the examples for identifiers at the end.
 If a library (or application) has instrumentation built-in, it is both the instrumenting and instrumented library and should pass its own name here. In all other cases (and to distinguish them from that case), the distinction between instrumenting and instrumented library is very important. For example, if an HTTP library `com.example.http` is instrumented by either `io.opentelemetry.contrib.examplehttp`, then it is important that the Tracer is not named `com.example.http`, but `io.opentelemetry.contrib.examplehttp` after the actual instrumentation library.
 
 If no name (null or empty string) is specified, following the suggestions in ["error handling proposal"](https://github.com/open-telemetry/opentelemetry-specification/pull/153), a "smart default" will be applied and a default Tracer / Meter implementation is returned.
diff --git a/oteps/0035-opentelemetry-protocol.md b/oteps/0035-opentelemetry-protocol.md
index 3292aeb888a..0ac70f7a9b8 100644
--- a/oteps/0035-opentelemetry-protocol.md
+++ b/oteps/0035-opentelemetry-protocol.md
@@ -193,7 +193,7 @@ When the client receives this signal it SHOULD follow the recommendations outlin
 // reached.
 ```
 
-The value of `retry_delay` is determined by the server and is implementation dependant. The server SHOULD choose a `retry_delay` value that is big enough to give the server time to recover, yet is not too big to cause the client to drop data while it is throttled.
+The value of `retry_delay` is determined by the server and is implementation dependent. The server SHOULD choose a `retry_delay` value that is big enough to give the server time to recover, yet is not too big to cause the client to drop data while it is throttled.
 
 #### gRPC Service Definition
 
@@ -232,7 +232,7 @@ This ensures that all destination servers receive the data regardless of their s
 
 #### Duplicate Data
 
-In edge cases (e.g. on reconnections, network interruptions, etc) the client has no way of knowing if recently sent data was delivered if no acknowledgement was received yet. The client will typically choose to re-send such data to guarantee delivery, which may result in duplicate data on the server side. This is a deliberate choice and is considered to be the right tradeoff for telemetry data.
+In edge cases (e.g. on reconnections, network interruptions, etc) the client has no way of knowing if recently sent data was delivered if no acknowledgement was received yet. The client will typically choose to re-send such data to guarantee delivery, which may result in duplicate data on the server-side. This is a deliberate choice and is considered to be the right trade-off for telemetry data.
 
 ### Partial Success
 
@@ -248,7 +248,7 @@ OTLP does not use explicit protocol version numbering. OTLP's interoperability o
 
 1. OTLP (current and future versions) defines a set of capabilities, some of which are mandatory, others are optional. Clients and servers must implement mandatory capabilities and can choose implement only a subset of optional capabilities.
 
-2. For minor changes to the protocol future versions and extension of OTLP are encouraged to use the ability of Protocol Buffers to evolve message schema in backwards compatible manner. Newer versions of OTLP may add new fields to messages that will be ignored by clients and servers that do not understand these fields. In many cases careful design of such schema changes and correct choice of default values for new fields is enough to ensure interoperability of different versions without nodes explicitly detecting that their peer node has different capabilities.
+2. For minor changes to the protocol future versions and extension of OTLP are encouraged to use the ability of Protocol Buffers to evolve message schema in backward compatible manner. Newer versions of OTLP may add new fields to messages that will be ignored by clients and servers that do not understand these fields. In many cases careful design of such schema changes and correct choice of default values for new fields is enough to ensure interoperability of different versions without nodes explicitly detecting that their peer node has different capabilities.
 
 3. More significant changes must be explicitly defined as new optional capabilities in future RFCs. Such capabilities SHOULD be discovered by client and server implementations after establishing the underlying transport. The exact discovery mechanism SHOULD be described in future RFCs which define the new capabilities and typically can be implemented by making a discovery request/response message exchange from the client to server. The mandatory capabilities defined by this specification are implied and do not require a discovery. The implementation which supports a new, optional capability MUST adjust its behavior to match the expectation of a peer that does not support a particular capability.
 
@@ -256,7 +256,7 @@ The current version of OTLP is the initial version that describes mandatory capa
 
 ## Prior Art, Alternatives and Future Possibilities
 
-We have considered using gRPC streaming instead of Unary RPC calls. This would require implementations to manually perform stream closing and opening periodically to be L7 Load Balancer friendly. Reference implementation using gRPC Streaming has shown that it results in significantly more complex and error prone code without significant benefits. Because of this Unary RPC was chosen.
+We have considered using gRPC streaming instead of Unary RPC calls. This would require implementations to manually perform stream closing and opening periodically to be L7 Load Balancer friendly. Reference implementation using gRPC Streaming has shown that it results in significantly more complex and error-prone code without significant benefits. Because of this Unary RPC was chosen.
 
 OTLP is an evolution of OpenCensus protocol based on the research and testing of its modifications in production at Omnition. The modifications include changes to data formats (see RFC0059), use of Unary PRC and backpressure signaling capability.
 
diff --git a/oteps/0038-version-semantic-attribute.md b/oteps/0038-version-semantic-attribute.md
index 0eac5c00bb4..9314eaf1c3a 100644
--- a/oteps/0038-version-semantic-attribute.md
+++ b/oteps/0038-version-semantic-attribute.md
@@ -19,7 +19,7 @@ The definition of a `version` is a key-value attribute pair of `string` to `stri
 available to hint at the type of a version, such as the following:
 
 `version=semver:1.2.3` (a semantic version)
-`version=git:8ae73a` (a git sha hash)
+`version=git:8ae73a` (a Git sha hash)
 `version=0.0.4.2.20190921` (a untyped version)
 
 ## Internal details
diff --git a/oteps/0099-otlp-http.md b/oteps/0099-otlp-http.md
index 6a18571843f..463a3309d8b 100644
--- a/oteps/0099-otlp-http.md
+++ b/oteps/0099-otlp-http.md
@@ -26,14 +26,14 @@ gRPC has certain benefits there are also drawbacks:
   usage impossible. For example AWS ALB does not support gRPC connections.
 
 - gRPC is a relatively big dependency, which some clients are not willing to
-  take. Plain HTTP is a smaller dependency and is built in the standard
+  take. Plain HTTP is a smaller dependency and is built-in the standard
   libraries of many programming languages.
 
 ## OTLP/HTTP Protocol Details
 
 This proposal keeps the existing specification of OTLP over gRPC transport
 (OTLP/gRPC for short) and defines an additional way to use OTLP protocol over
-HTTP transport (OTLP/HTTP for short). OTLP/HTTP uses the same ProtoBuf payload
+HTTP transport (OTLP/HTTP for short). OTLP/HTTP uses the same protobuf payload
 that is used by OTLP/gRPC and defines how this payload is communicated over HTTP
 transport.
 
diff --git a/oteps/0111-auto-resource-detection.md b/oteps/0111-auto-resource-detection.md
index 8af2c14e88a..c6c9db144cb 100644
--- a/oteps/0111-auto-resource-detection.md
+++ b/oteps/0111-auto-resource-detection.md
@@ -8,7 +8,7 @@ Resource information, i.e. attributes associated with the entity producing
 telemetry, can currently be supplied to tracer and meter providers or appended
 in custom exporters. In addition to this, it would be useful to have a mechanism
 to automatically detect resource information from the host (e.g. from an
-environment variable or from aws, gcp, etc metadata) and apply this to all kinds
+environment variable or from AWS, GCP, etc metadata) and apply this to all kinds
 of telemetry. This will in many cases prevent users from having to manually
 configure resource information.
 
@@ -31,7 +31,7 @@ the order the detectors were added.
 
 A default implementation of a detector that reads resource data from the
 `OTEL_RESOURCE` environment variable will be included in the SDK. The
-environment variable will contain of a list of key value pairs, and these are
+environment variable will contain of a list of key-value pairs, and these are
 expected to be represented in a format similar to the [W3C
 Baggage](https://github.com/w3c/baggage/blob/main/baggage/HTTP_HEADER_FORMAT.md#header-content),
 except that additional semi-colon delimited metadata is not supported, i.e.:
@@ -165,7 +165,7 @@ specification](https://github.com/census-instrumentation/opencensus-specs/blob/m
 
 - Does this interfere with any other upcoming specification changes related to
   resources?
-- If custom detectors need to live outside the core repo, what is the
+- If custom detectors need to live outside the core repository, what is the
   expectation regarding where they should be hosted?
 - Also see the [Trade-offs and mitigations](#trade-offs-and-mitigations) section
 
diff --git a/oteps/0119-standard-system-metrics.md b/oteps/0119-standard-system-metrics.md
index 2fcb473b7af..2b6a7f4a9fc 100644
--- a/oteps/0119-standard-system-metrics.md
+++ b/oteps/0119-standard-system-metrics.md
@@ -6,7 +6,7 @@ This OTEP is largely based on the existing implementation in the OpenTelemetry C
 
 ## Trade-offs and mitigations
 
-When naming a metric instrument, there is a trade off between discoverability and ambiguity. For example, a metric called `system.cpu.load_average` is very discoverable, but the meaning of this metric is ambiguous. [Load average](https://en.wikipedia.org/wiki/Load_(computing)) is well defined on UNIX, but is not a standard metric on Windows. While discoverability is important, names must be unambiguous.
+When naming a metric instrument, there is a trade-off between discoverability and ambiguity. For example, a metric called `system.cpu.load_average` is very discoverable, but the meaning of this metric is ambiguous. [Load average](https://en.wikipedia.org/wiki/Load_(computing)) is well defined on UNIX, but is not a standard metric on Windows. While discoverability is important, names must be unambiguous.
 
 ## Prior art
 
@@ -61,9 +61,9 @@ In the tables below, units of `1` refer to a ratio value that is always in the r
 |Name                  |Units  |Instrument Type  |Value Type|Label Key|Label Values                       |
 |----------------------|-------|-----------------|----------|---------|-----------------------------------|
 |system.cpu.time       |seconds|SumObserver      |Double    |state    |idle, user, system, interrupt, etc.|
-|                      |       |                 |          |cpu      |1 - #cores                         |
+|                      |       |                 |          |CPU      |1 - #cores                         |
 |system.cpu.utilization|1      |UpDownSumObserver|Double    |state    |idle, user, system, interrupt, etc.|
-|                      |       |                 |          |cpu      |1 - #cores                         |
+|                      |       |                 |          |CPU      |1 - #cores                         |
 
 #### `system.memory.`
 
@@ -149,7 +149,7 @@ Some programming languages have multiple runtime environments that vary signific
 ## Open questions
 
 - Should the individual runtimes have their specific naming conventions in the spec?
-- Is it ok to include instruments specific to an OS (or OS family) under a top-level prefix, as long as they are unambiguous? For example, naming inode related instruments, which of the below is preferred?
+- Is it OK to include instruments specific to an OS (or OS family) under a top-level prefix, as long as they are unambiguous? For example, naming inode related instruments, which of the below is preferred?
   1. Top level: `system.filesystem.inodes.*`
   2. UNIX family level: `system.unix.filesystem.inodes.*`
   3. One for each UNIX OS: `system.linux.filesystem.inodes.*`, `system.freebsd.filesystem.inodes.*`, `system.netbsd.filesystem.inodes.*`, etc.
diff --git a/oteps/0122-otlp-http-json.md b/oteps/0122-otlp-http-json.md
index f2a42d4d4ec..336bf05cd91 100644
--- a/oteps/0122-otlp-http-json.md
+++ b/oteps/0122-otlp-http-json.md
@@ -1,6 +1,6 @@
 # OTLP: JSON Encoding for OTLP/HTTP
 
-This is a proposal to add HTTP Transport extension supporting json serialization for
+This is a proposal to add HTTP Transport extension supporting JSON serialization for
 [OTLP](0035-opentelemetry-protocol.md) (OpenTelemetry Protocol).
 
 ## Table of Contents
@@ -19,7 +19,7 @@ This is a proposal to add HTTP Transport extension supporting json serialization
 
 ## Motivation
 
-Protobuf is a relatively big dependency, which some clients are not willing to take. For example, WebJS, iOS/Android (in some scenarios, the size of the installation package is limited, do not want to introduce protobuf dependencies). Plain JSON is a smaller dependency and is built in the standard libraries of many programming languages.
+Protobuf is a relatively big dependency, which some clients are not willing to take. For example, WebJS, iOS/Android (in some scenarios, the size of the installation package is limited, do not want to introduce protobuf dependencies). Plain JSON is a smaller dependency and is built-in the standard libraries of many programming languages.
 
 ## OTLP/HTTP+JSON Protocol Details
 
@@ -27,7 +27,7 @@ OTLP/HTTP+JSON will be consistent with the [OTLP/HTTP](0099-otlp-http.md) specif
 
 ### JSON Mapping
 
-Use proto3 standard defined [JSON Mapping](https://protobuf.dev/programming-guides/proto3/#json) for mapping between protobuf and json. `trace_id`  and `span_id` is base64 encoded in OTLP/HTTP+JSON, not hex.
+Use proto3 standard defined [JSON Mapping](https://protobuf.dev/programming-guides/proto3/#json) for mapping between protobuf and JSON. `trace_id`  and `span_id` is base64 encoded in OTLP/HTTP+JSON, not hex.
 
 ### Request
 
diff --git a/oteps/0143-versioning-and-stability.md b/oteps/0143-versioning-and-stability.md
index ba46423f3aa..27dfdadf8a1 100644
--- a/oteps/0143-versioning-and-stability.md
+++ b/oteps/0143-versioning-and-stability.md
@@ -27,7 +27,7 @@ Each signal provides a mechanism for software to describe itself. A codebase, su
 
 OpenTelemetry is designed to separate the portion of each signal which must be imported as cross-cutting concerns from the portions of OpenTelemetry which can be managed independently. OpenTelemetry is also designed to be an extensible framework. To accomplish this these goals, each signal consists of four types of packages:
 
-**API -** API packages consist of the cross-cutting public interfaces used for instrumentation. Any portion of OpenTelemetry which 3rd-party libraries and application code depend upon is considered part of the API. To manage different levels of stability, every signal has its own, independent API package. These individual APIs may also be bundled up into a shared global API, for convenience.
+**API -** API packages consist of the cross-cutting public interfaces used for instrumentation. Any portion of OpenTelemetry which third-party libraries and application code depend upon is considered part of the API. To manage different levels of stability, every signal has its own, independent API package. These individual APIs may also be bundled up into a shared global API, for convenience.
 
 **SDK -** The implementation of the API. The SDK is managed by the application owner. Note that the SDKs includes additional public interfaces which are not considered part of the API package, as they are not cross-cutting concerns. These public interfaces are defined as **constructors** and **plugin interfaces**. Examples of plugin interfaces include the SpanProcessor, Exporter, and Sampler interfaces. Examples of constructors include configuration objects, environment variables, and SDK builders. Application owners may interact with SDK constructors; plugin authors may interact with SDK plugin interfaces. Instrumentation authors must never directly reference any SDK package of any kind, only the API.
 
@@ -65,7 +65,7 @@ Once a signal component is marked as stable, the following rules apply until the
 No backward-incompatible changes to the API are allowed unless the major version number is incremented. All existing API calls must continue to compile and function against all future minor versions of the same major version. ABI compatibility for the API may be offered on a language by language basis.
 
 **SDK Stability -**
-Public portions of the SDK must remain backwards compatible. There are two categories: **plugin interfaces** and **constructors**. Examples of plugins include the SpanProcessor, Exporter, and Sampler interfaces. Examples of constructors include configuration objects, environment variables, and SDK builders.
+Public portions of the SDK must remain backward compatible. There are two categories: **plugin interfaces** and **constructors**. Examples of plugins include the SpanProcessor, Exporter, and Sampler interfaces. Examples of constructors include configuration objects, environment variables, and SDK builders.
 
 ABI compatibility for SDK plugin interfaces and constructors may be offered on a language by language basis.
 
@@ -75,15 +75,15 @@ Semantic Conventions may not be removed once they are stable. New conventions ma
 **Contrib Stability -**
 Plugins and instrumentation are kept up to date, and are released simultaneously (or shortly after) the latest release of the API. The goal is to ensure users can update to the latest version of OpenTelemetry, and not be held back by the plugins that they depend on.
 
-Public portions of contrib packages (constructors, configuration, interfaces) must remain backwards compatible. ABI compatibility for contrib packages may be offered on a language by language basis.
+Public portions of contrib packages (constructors, configuration, interfaces) must remain backward compatible. ABI compatibility for contrib packages may be offered on a language by language basis.
 
-Telemetry produced by contrib instrumentation must also remain stable and backwards compatible, to avoid breaking alerts and dashboards. This means that existing data may not be mutated or removed without a major version bump. Additional data may be added. This applies to spans, metrics, resources, attributes, events, and any other data types that OpenTelemetry emits.
+Telemetry produced by contrib instrumentation must also remain stable and backward compatible, to avoid breaking alerts and dashboards. This means that existing data may not be mutated or removed without a major version bump. Additional data may be added. This applies to spans, metrics, resources, attributes, events, and any other data types that OpenTelemetry emits.
 
 ### Deprecation
 
 In theory, signals could be replaced. When this happens, they are marked as deprecated.
 
-Code is only marked as deprecated when the replacement becomes stable. Deprecated code still abides by the same support guarantees as stable code. Deprecated APIs remain stable and backwards compatible.
+Code is only marked as deprecated when the replacement becomes stable. Deprecated code still abides by the same support guarantees as stable code. Deprecated APIs remain stable and backward compatible.
 
 ### Removal
 
@@ -99,7 +99,7 @@ This is not actually a theoretical example. OpenTelemetry already supports two t
 
 ## Version Numbers
 
-OpenTelemetry follows [semver 2.0](https://semver.org/) conventions, with the following distinction.
+OpenTelemetry follows [SemVer 2.0](https://semver.org/) conventions, with the following distinction.
 
 OpenTelemetry clients have four components: API, Semantic Conventions, SDK, and Contrib.
 
@@ -113,7 +113,7 @@ For the purposes of versioning, all code within a component is treated as if it
 * Different language implementations do not need to have matching version numbers. For example, it is fine to have `opentelemetry-python-api` at v1.2.8 when `opentelemetry-java-api` is at v1.3.2.
 * Language implementations do not need to match the version of the specification they implement. For example, it is fine for v1.8.2 of `opentelemetry-python-api` to implement v1.1.1 of the specification.
 
-**Exception:** in some languages, package managers may react poorly to experimental packages having a version higher than 0.X. In these cases, a language-specific workaround is required. Go, Ruby, and Javascript are examples.
+**Exception:** in some languages, package managers may react poorly to experimental packages having a version higher than 0.X. In these cases, a language-specific workaround is required. Go, Ruby, and JavaScript are examples.
 
 **Major version bump**
 Major version bumps only occur when there is a breaking change to a stable interface, or the removal of deprecated signals.
diff --git a/oteps/0147-upgrade-procedures.md b/oteps/0147-upgrade-procedures.md
index ef3b94e620a..f46b0d6a4e3 100644
--- a/oteps/0147-upgrade-procedures.md
+++ b/oteps/0147-upgrade-procedures.md
@@ -26,7 +26,7 @@ Before we get into the design requirements, here’s how upgrading actually work
 
 ### API changes
 
-When new functionality is added to the OpenTelemetry API, a new minor version of the API is released. These API changes are always additive and backwards compatible from the perspective of existing Instrumentation packages which import and call prior versions. Instrumentation written against all prior minor versions of the API continues to work, and may be composed together into the same application without creating a dependency conflict.
+When new functionality is added to the OpenTelemetry API, a new minor version of the API is released. These API changes are always additive and backward compatible from the perspective of existing Instrumentation packages which import and call prior versions. Instrumentation written against all prior minor versions of the API continues to work, and may be composed together into the same application without creating a dependency conflict.
 
 API implementations are expected to always target the latest version of the API. When a new version of the API is released, a version of the SDK which supports the API is released in tandem. New versions of the API are not expected to support older versions of the SDK.
 
diff --git a/oteps/0149-exponential-histogram.md b/oteps/0149-exponential-histogram.md
index 33fa426a961..0a34cb3ab9c 100644
--- a/oteps/0149-exponential-histogram.md
+++ b/oteps/0149-exponential-histogram.md
@@ -4,11 +4,11 @@ Add exponential bucketing to histogram protobuf
 
 ## Motivation
 
-Currently, the OTEL protobuf [protocol](https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/metrics/v1/metrics.proto) only supports explicit bound buckets. Each bucket's bound and count must be explicitly defined. This is inefficient to transport buckets whose bounds have a pattern, such as exponential (ie. log scale) buckets. More importantly, without bucket pattern info, the receiver may not be able to optimize its processing on these buckets. With a protocol that also supports exponential buckets, the bounds can be encoded with just a few parameters, regardless of the number of buckets, and the receiver can optimize processing based on the knowledge that these buckets are exponential.
+Currently, the OTel protobuf [protocol](https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/metrics/v1/metrics.proto) only supports explicit bound buckets. Each bucket's bound and count must be explicitly defined. This is inefficient to transport buckets whose bounds have a pattern, such as exponential (ie. log scale) buckets. More importantly, without bucket pattern info, the receiver may not be able to optimize its processing on these buckets. With a protocol that also supports exponential buckets, the bounds can be encoded with just a few parameters, regardless of the number of buckets, and the receiver can optimize processing based on the knowledge that these buckets are exponential.
 
 The explicit bucket type will be kept, as a fallback for arbitrary bucket bounds. For example, Prometheus histograms often come with arbitrary user defined bounds.
 
-Exponential buckets are chosen to be added because they are very good at representing [long tail](https://en.wikipedia.org/wiki/Long_tail) distributions, which are common in the OTEL target application like response time measurement. Exponential buckets (ie. log scale buckets) need far fewer buckets than linear scale buckets to cover the wide range of a long tail distribution. Furthermore, percentiles/quantiles can be computed from exponential buckets with constant relative error across the full range.
+Exponential buckets are chosen to be added because they are very good at representing [long tail](https://en.wikipedia.org/wiki/Long_tail) distributions, which are common in the OTel target application like response time measurement. Exponential buckets (ie. log scale buckets) need far fewer buckets than linear scale buckets to cover the wide range of a long tail distribution. Furthermore, percentiles/quantiles can be computed from exponential buckets with constant relative error across the full range.
 
 ## Explanation
 
@@ -87,7 +87,7 @@ Such "2 to 1" binary merge has the following benefits:
 
 A histogram producer may implement "auto scale" to control memory cost. With a reasonable default config on target relative error and max number of buckets, the producer could operate in an "automagic" fashion. The producer can start with a base at target resolution, and dynamically change the scale if incoming data's range would make the histogram exceed the memory limit. [New Relic](https://docs.newrelic.com/docs/data-apis/understand-data/metric-data/metric-data-type/) and [Google](https://github.com/open-telemetry/opentelemetry-proto/pull/226#issuecomment-737496026) have implemented such logic for internal use. Open source versions from these companies are in plan.
 
-The main disadvantage of scaled exponential histogram is not supporting arbitrary base. The base can only increase by square, or decrease by square root. Unless a user's target relative error is exactly on the series, they have to choose the next smaller base, which costs more space for the target. But in return, you get universally mergeable histograms, which seems like a reasonable trade off. As shown in discussions below, typically, the user has the choice around 1%, 2%, or 4% errors. Since error target is rarely precise science, choosing from the limited menu does not add much burden to the user.
+The main disadvantage of scaled exponential histogram is not supporting arbitrary base. The base can only increase by square, or decrease by square root. Unless a user's target relative error is exactly on the series, they have to choose the next smaller base, which costs more space for the target. But in return, you get universally mergeable histograms, which seems like a reasonable trade-off. As shown in discussions below, typically, the user has the choice around 1%, 2%, or 4% errors. Since error target is rarely precise science, choosing from the limited menu does not add much burden to the user.
 
 **If we can agree on a "referenceBase", then we have universally mergeable histograms.** In [#226](https://github.com/open-telemetry/opentelemetry-proto/pull/226#issuecomment-777922339), a referenceBase of 2 was proposed. The general form for the series is
 
diff --git a/oteps/0152-telemetry-schemas.md b/oteps/0152-telemetry-schemas.md
index 344ad4bb255..dfcd6ea9efa 100644
--- a/oteps/0152-telemetry-schemas.md
+++ b/oteps/0152-telemetry-schemas.md
@@ -232,10 +232,10 @@ time with OpenTelemetry Collector's schema translation processor).
 
 ## Schema Version Number
 
-Version number follows the MAJOR.MINOR.PATCH format, similar to semver 2.0.
+Version number follows the MAJOR.MINOR.PATCH format, similar to SemVer 2.0.
 
 Version numbers use the [ordering rules](https://semver.org/#spec-item-11)
-defined by semver 2.0 specification. See how ordering is used in the
+defined by SemVer 2.0 specification. See how ordering is used in the
 [Order of Transformations](#order-of-transformations). Other than the ordering
 rules the schema version numbers do not carry any other semantic meaning.
 
@@ -320,7 +320,7 @@ previous version to this version.
 The "changes" section is a sequence of transformations. Only one transformation
 is supported for section "all": "rename_attributes" transformation.
 
-"rename_attributes" transformation requires a map of key/value pairs, where the
+"rename_attributes" transformation requires a map of key-value pairs, where the
 key is the old name of the attribute used in the previous version, the value is
 the new name of the attribute starting from this version. Here is the structure:
 
@@ -552,7 +552,7 @@ individual transformation also performing the reverse conversion.
 ### Schema File Format Number
 
 The "file_format" setting in the schema file specifies the format version of the
-file. The format version follows the MAJOR.MINOR.PATCH format, similar to semver
+file. The format version follows the MAJOR.MINOR.PATCH format, similar to SemVer
 2.0.
 
 The "file_format" setting is used by consumers of the file to know if they are
@@ -747,7 +747,7 @@ Depending on the language the following approaches are possible:
   likely breaks the ABI.
 
 - Add a method overload that allows passing 3 parameters (instrumentation
-  library name, version and schema url) to obtain a Tracer/Meter/LogEmitter.
+  library name, version and schema URL) to obtain a Tracer/Meter/LogEmitter.
   This is likely the preferred approach for languages where method overloads are
   possible.
 
@@ -775,7 +775,7 @@ convention helpers the library uses (e.g. constants that define the semantic
 conventions) match exactly that same schema version? One possible solution is to
 introduce helper packages per schema version that the libraries can use, e.g.
 constants that define the semantic conventions and the corresponding schema
-version url. This should be likely the topic for a follow-up OTEP.
+version URL. This should be likely the topic for a follow-up OTEP.
 
 ### Application-wide Schema URL
 
@@ -788,8 +788,8 @@ If the user does not set an application-wide Schema URL then the current Schema
 URL MUST be populated by OTLP Exporter in the messages, where "current" means
 the version of OpenTelemetry Schema against which the SDK is coded.
 
-Note that if there is a schema url associated with instrumentation library it
-overrides the application-wide schema url as described [here](#otlp-changes).
+Note that if there is a schema URL associated with instrumentation library it
+overrides the application-wide schema URL as described [here](#otlp-changes).
 
 ## OpenTelemetry Schema
 
@@ -836,8 +836,8 @@ version to another is performed using a Go implementation.
 The benchmark does the following:
 
 - Compares the CPU time necessary for schema conversion to the time necessary
-  for Protobuf decoding. This is a useful comparison because telemetry consumers
-  have to perform Protobuf decoding so it is the minimum baseline work against
+  for protobuf decoding. This is a useful comparison because telemetry consumers
+  have to perform protobuf decoding so it is the minimum baseline work against
   which we can measure the impact of the additional conversion work.
 
 - Uses a hypothetical schema version change where 20 attributes in semantic
@@ -869,7 +869,7 @@ consumers do).
 
 ## Open Questions
 
-- Do we need to support a concept of "pre-release" semantic conventions that can
+- Do we need to support a concept of "prerelease" semantic conventions that can
   be broken freely and are not part of strict schema checks? Supposedly, this is
   already possible simply by avoiding introducing a new schema version when such
   semantic conventions change.
@@ -879,7 +879,7 @@ consumers do).
   helpers the library uses (e.g. constants that define the semantic conventions)
   match exactly that same schema version? One possible solution is to introduce
   helper packages per schema version that the libraries can use, e.g. constants
-  that define the semantic conventions and the corresponding schema version url.
+  that define the semantic conventions and the corresponding schema version URL.
   This should be likely the topic for a follow-up OTEP.
 
 - Should we make it possible to include the entire Schema File in OTLP requests
@@ -924,7 +924,7 @@ open up a few interesting possibilities:
 
 - OpenTelemetry semantic conventions document can be automatically generated
   from this formal schema file. This will remove the need to have semantic
-  conventions codified and generated from yaml files in the specification.
+  conventions codified and generated from YAML files in the specification.
 
 - Consumers of telemetry can use this information to interpret the received
   telemetry.
@@ -1047,7 +1047,7 @@ The downsides are:
 
 ## Prior Art
 
-- [OpenTelemetry Log Data Model: Body Meta-Data](https://docs.google.com/document/d/1ZExye1lW43owwaxcbjOvl0P2qER-UaYd_MyxItc2h0k/edit#)
+- [OpenTelemetry Log Data Model: Body Metadata](https://docs.google.com/document/d/1ZExye1lW43owwaxcbjOvl0P2qER-UaYd_MyxItc2h0k/edit#)
   by Christian Beedgen.
 
 - [Generic event encoding schemas](https://docs.google.com/document/d/11ccT_zBbiCfwKyi6TMuy2sA3nUdElNQsDJOQ79icVKs/edit#)
diff --git a/oteps/0155-external-modules.md b/oteps/0155-external-modules.md
index 68d85e7b8b2..042a868ab9c 100644
--- a/oteps/0155-external-modules.md
+++ b/oteps/0155-external-modules.md
@@ -9,7 +9,7 @@ including integrations with various libraries and frameworks in all languages su
 We cannot possibly expect that all these integrations will be provided by the core maintainers of OpenTelemetry.
 We hope that wider community will integrate their projects with OpenTelemetry.
 We have to encourage that by providing great documentation, examples and tooling to integration authors,
-while still providing our end-users with some way to discover all available OpenTelemetry components together with some visibility into their quality.
+while still providing our end users with some way to discover all available OpenTelemetry components together with some visibility into their quality.
 
 ## Explanation
 
@@ -45,8 +45,8 @@ All instances of core instrumentation must be included into the OpenTelemetry Re
 
 ### Contrib components
 
-Any language SIG may have one or more “contrib” repos containing components contributed by developers with an interest in specific parts of the instrumentation ecosystem.
-These repositories may have a separate set of approvers/maintainers than the core API/SDK repo.
+Any language SIG may have one or more “contrib” repositories containing components contributed by developers with an interest in specific parts of the instrumentation ecosystem.
+These repositories may have a separate set of approvers/maintainers than the core API/SDK repository.
 Contrib repositories are as important for the project success as core repository, but may not require the same level of expertise.
 In fact, these repositories often calls for other set of skills and customer's understanding.
 On contrib repository creation, new set of approvers and maintainers can be added as we do for any new repository, without time/contribution requirements.
@@ -54,13 +54,13 @@ Repository maintainers are also encouraged to promote contributors to approver/m
 based on targeted contributions and expertise of the contrib repository rather than overall SIG scope.
 It is important to keep the process fair and inclusive by following the formal guidance published [here](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#maintainer).
 A contrib repository may leverage the CODEOWNERS functionality of GitHub to assign maintainers to individual packages
-even if this means granting write permissions to the whole repo.
+even if this means granting write permissions to the whole repository.
 The goal should be to distribute the load of reviewing PRs and accepting changes as much as possible, while keeping reliability and overall quality of components and fair governance.
 
 All components in a contrib repository are expected to be included into the OpenTelemetry Registry following the usual process described above.
 
 We should welcome all contributions and make the inclusion process (including following all our requirements) as easy as possible.
-The goal is to encourage all contributors to include their components into a contrib repo as opposed to hosting them separately.
+The goal is to encourage all contributors to include their components into a contrib repository as opposed to hosting them separately.
 This way they can reuse existing infrastructure for testing, publishing, security scanning etc.
 This will also greatly simplify responsibility transfer between different maintainers if their priorities change.
 It also promotes the development and maintenance of a single instrumentation package for each instrumentation source,
@@ -85,7 +85,7 @@ Their submission for inclusion into OpenTelemetry Registry is still welcomed, su
 ### Distribution
 
 Whenever OpenTelemetry components are published to any repository other than the OpenTelemetry Registry (such as npm registry or Maven Central),
-only core and contrib components can be published under "opentelemetry" namespace.
+only core and contrib components can be published under "OpenTelemetry" namespace.
 Native and external components are to be published under their own namespace.
 
 In case the OpenTelemetry SIG provides any kind of "all-in-one" instrumentation distribution (e.g. as Java and .NET do)
@@ -97,7 +97,7 @@ This may mean a separate language-specific component API that all components are
 
 ## Trade-offs and mitigations
 
-* How easy it is to get merge permission in contrib repo?
+* How easy it is to get merge permission in contrib repository?
 The harder it is, the larger is the maintenance burden on the core team.
 The easier it is, the more uncertainty there is about the quality of contributions.
 Can every language SIG decide this for themselves or should we decide together?
diff --git a/oteps/0156-columnar-encoding.md b/oteps/0156-columnar-encoding.md
index 93b438c3f0a..7fe0e41b2ce 100644
--- a/oteps/0156-columnar-encoding.md
+++ b/oteps/0156-columnar-encoding.md
@@ -86,7 +86,7 @@ OpenTelemetry protocol this compatible extension has the following improvements:
   aggregation, and filtering.
 
 These improvements not only address the aforementioned needs but also answer the [open questions](0035-opentelemetry-protocol.md#open-questions)
-cited in OTEP 035 (i.e. cpu usage, memory pressure, compression optimization).
+cited in OTEP 035 (i.e. CPU usage, memory pressure, compression optimization).
 
 **It is important to understand that this proposal is complementary to the existing protocol. The row-oriented version
 is still suitable for some scenarios. Telemetry sources that generate a small amount of telemetry data should continue
@@ -184,7 +184,7 @@ format.
 
 This first step is intended to address the specific use cases of **traffic reduction** and native support of
 **multivariate time-series**. Based on community feedback, many companies want to reduce the cost of transferring
-telemetry data over the Internet. By adding a collector that acts as a point of integration and traffic conversion at
+telemetry data over the internet. By adding a collector that acts as a point of integration and traffic conversion at
 the edge of a client environment, we can take advantage of the columnar format to eliminate redundant data and optimize
 the compression ratio. This is illustrated in the following diagram.
 
@@ -303,7 +303,7 @@ message BatchArrowRecords {
 ```
 
 The `batch_id` attribute is a unique identifier for the batch inside the scope of the current stream. It is used to
-uniquely identify the batch in the server message `BatchStatus` stream. See the [Batch Id generation](#batch-id-generation)
+uniquely identify the batch in the server message `BatchStatus` stream. See the [Batch ID generation](#batch-id-generation)
 section for more information on the implementation of this identifier.
 
 The `arrow_payloads` attribute is a list of `ArrowPayload` messages. Each `ArrowPayload` message represents
@@ -381,8 +381,8 @@ message ArrowPayload {
 ```
 
 The `schema_id` attribute is a unique identifier representing the schema of the Arrow Record present in the
-`ArrowPayload`. This id will be used receiver side to keep track of the schema and dictionaries for a
-specific type of Arrow Records. See the [Schema Id generation](#schema-id-generation) section for more information
+`ArrowPayload`. This ID will be used receiver side to keep track of the schema and dictionaries for a
+specific type of Arrow Records. See the [Schema ID generation](#schema-id-generation) section for more information
 on the implementation of this identifier.
 
 The `ArrowPayloadType` enum specifies the `type` of the payload.
@@ -622,7 +622,7 @@ in both.  With every collector release we merge the OTel Arrow changes
 with the mainline components to maintain this promise of
 compatibility.
 
-OTel Arrow supports conveying the gRPC metadata (i.e., http2 headers) using a dedicated `bytes` field.  Metadata is
+OTel Arrow supports conveying the gRPC metadata (i.e., HTTP/2 headers) using a dedicated `bytes` field.  Metadata is
 encoded using [hpack](https://datatracker.ietf.org/doc/rfc7541/) like a typical unary gRPC request.
 
 Specifically:
@@ -661,7 +661,7 @@ The `batch_id` attribute is used by the message delivery mechanism. Each `BatchA
 unique `batch_id`. Uniqueness must be ensured in the scope of the stream opened by the call to the `ArrowStreamService`.
 This `batch_id` will be used in the `BatchStatus` object to acknowledge receipt and processing of the corresponding
 batch.
-A numeric counter is used to implement this batch_id, the goal being to use the most concise id possible.
+A numeric counter is used to implement this batch_id, the goal being to use the most concise ID possible.
 
 ### Schema ID Generation
 
@@ -669,7 +669,7 @@ Within the collector, batching, filtering, exporting, ... operations require to
 compatible schema. A synthetic identifier (or `schema_id`) must be computed for each `ArrowPayload` to perform this
 grouping.
 
-We recommend calculating the schema id in the following way:
+We recommend calculating the schema ID in the following way:
 
 * for each Arrow Schema create a list of triples (name, type, metadata) for each column.
 * sort these triples according to a lexicographic order.
@@ -680,8 +680,8 @@ We recommend calculating the schema id in the following way:
 
 To mitigate the usual pitfalls of a stream-oriented protocol, protocol implementers are advised to:
 
-* client side: create several streams in parallel (e.g. create a new stream every 10 event types),
-* server side: close streams that have been open for a long time (e.g. close stream every 1 hour).
+* client-side: create several streams in parallel (e.g. create a new stream every 10 event types),
+* server-side: close streams that have been open for a long time (e.g. close stream every 1 hour).
 
 These parameters must be exposed in a configuration file and be tuned according to the application.
 
@@ -738,8 +738,8 @@ specification reuses the authentication mechanisms already in place in the colle
 
 In edge cases (e.g. on reconnections, network interruptions, etc) the client has no way of knowing if recently sent data
 was delivered if no acknowledgement was received yet. The client will typically choose to re-send such data to guarantee
-delivery, which may result in duplicate data on the server side. This is a deliberate choice and is considered to be the
-right tradeoff for telemetry data. This can be mitigated by using an idempotent insertion mechanism at the data backend
+delivery, which may result in duplicate data on the server-side. This is a deliberate choice and is considered to be the
+right trade-off for telemetry data. This can be mitigated by using an idempotent insertion mechanism at the data backend
 level.
 
 ### Incompatible Backends
@@ -1010,7 +1010,7 @@ updated.
 A multivariate time series has more than one time-dependent variable. Each variable depends not only on
 its past values but also has some dependency on other variables. A 3 axis accelerometer reporting 3 metrics
 simultaneously; a mouse move that simultaneously reports the values of x and y, a meteorological weather station
-reporting temperature, cloud cover, dew point, humidity and wind speed; an http transaction characterized by many
+reporting temperature, cloud cover, dew point, humidity and wind speed; an HTTP transaction characterized by many
 interrelated metrics sharing the same attributes are all common examples of multivariate time-series.
 
 ## Acknowledgements
diff --git a/oteps/0199-support-elastic-common-schema-in-opentelemetry.md b/oteps/0199-support-elastic-common-schema-in-opentelemetry.md
index 512e7407b3b..cc152bafb13 100644
--- a/oteps/0199-support-elastic-common-schema-in-opentelemetry.md
+++ b/oteps/0199-support-elastic-common-schema-in-opentelemetry.md
@@ -8,7 +8,7 @@ This proposal is to merge the Elastic Common Schema (ECS) with the OpenTelemetry
 
 - Long-term, ECS and OTel SemConv will converge into one open standard that is maintained by OpenTelemetry. To kick off this effort, Elastic will nominate several domain experts to join the OpenTelemetry Semantic Convention Approvers to help with maintaining the new standard.
 - OTel SemConv will adopt ECS in its full scope (except for individual adjustments in detail where inevitable), including the logging, observability and security domain fields, to make the new schema a true successor of ECS and OTel SemConv.
-- Elastic and OpenTelemetry will coordinate and officially announce the direction of the merger (e.g. through official websites, blog posts, etc.)
+- Elastic and OpenTelemetry will coordinate and officially announce the direction of the merger (e.g. through official sites, blog posts, etc.)
 - Migrate ECS and OTel SemConv users to the new common schema over time and provide utilities to allow the migration to be as easy as possible.
 
 ## Scope and Overlap of ECS and OTel SemConv
@@ -28,7 +28,7 @@ ECS and OTel SemConv have some overlap today, but also significant areas of mutu
 
 The process of merging ECS with OTel SemConv will take time and we propose to do it as part of the stabilization effort for OTel SemConv. During that period and also for a significant period after the merger (sunset period), Elastic will continue to support ECS as a schema. However, further evolution of ECS will happen on the basis of the new, common schema. Elastic will nominate ECS experts to help with maintaining the new schema and will require the approver role for the semantic conventions in OpenTelemetry for the new schema.
 
-With the merger there will be different categories of field conflicts between ECS fields and Otel SemConv attributes (as illustrated in the above figure). We expect the areas `A` and `B` to be less controversial and potentially low-hanging fruits for an enriched, new schema.
+With the merger there will be different categories of field conflicts between ECS fields and OTel SemConv attributes (as illustrated in the above figure). We expect the areas `A` and `B` to be less controversial and potentially low-hanging fruits for an enriched, new schema.
 
 For the areas `C` and `D` we propose to resolve conflicts through a close collaboration as part of the stabilization initiative of the OTel SemConv. Where feasible, the goal is to align the OTel SemConv attributes as close as possible with the existing, stable ECS fields. Where alignment is not feasible, the goal is to identify ways to address field conflicts through technical transformations and aliasing, to bridge existing fields and formats into the new schema and vice versa (e.g. through OpenTelemetry Collector Processors).
 
@@ -36,7 +36,7 @@ While realistically truly breaking changes on ECS and OTel SemConv won't be avoi
 
 ## Motivation
 
-Adding the Elastic Common Schema (ECS) to OpenTelemetry (OTel) is a great way to accelerate the integration of vendor-created logging and OTel component logs (i.e. OTel Collector Logs Receivers). The goal is to define vendor neutral semantic conventions for most popular types of systems and support vendor-created or open-source components (for example HTTP access logs, network logs, system access/authentication logs) extending OTel correlation to these new signals.
+Adding the Elastic Common Schema (ECS) to OpenTelemetry (OTel) is a great way to accelerate the integration of vendor-created logging and OTel component logs (i.e. OTel Collector Logs Receivers). The goal is to define vendor neutral semantic conventions for most popular types of systems and support vendor-created or open source components (for example HTTP access logs, network logs, system access/authentication logs) extending OTel correlation to these new signals.
 
 Adding the coverage of ECS to OTel would provide guidance to authors of OpenTelemetry Collector Logs Receivers and help establish the OTel Collector as a de facto standard log collector with a well-defined schema to allow for richer data definition.
 
@@ -44,7 +44,7 @@ In addition to the use case of structured logs, the maturity of ECS for SIEM (Se
 
 Another significant use case is providing first-class support for Kubernetes application logs, system logs, and application introspection events. We would also like to see support for structured events (e.g. [`k8seventsreceiver`](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/k8seventsreceiver)) and using 'content-type' to identify event types.
 
-We'd like to see different categories of structured logs being well-supported in the [OTel Log Data Model](../specification/logs/data-model.md), presumably through [semantic conventions for log attributes](../specification/logs/data-model.md#field-attributes). For example, NGINX access logs and Apache access logs should be processed the same way as structured logs. This would help in trace and metric correlation with such log data as well as it would help grow the ecosystem of curated UIs provided by observability backends and monitoring dashboards (e.g. one single HTTP access log dashboard benefiting Apache httpd, Nginx, and HAProxy).
+We'd like to see different categories of structured logs being well-supported in the [OTel Log Data Model](../specification/logs/data-model.md), presumably through [semantic conventions for log attributes](../specification/logs/data-model.md#field-attributes). For example, NGINX access logs and Apache access logs should be processed the same way as structured logs. This would help in trace and metric correlation with such log data as well as it would help grow the ecosystem of curated UIs provided by observability backends and monitoring dashboards (e.g. one single HTTP access log dashboard benefiting Apache httpd, NGINX, and HAProxy).
 
 ## Customer Motivation
 
@@ -52,7 +52,7 @@ Adoption of OTel logs will accelerate greatly if ECS is leveraged as the common
 
 Customers will benefit from turnkey logs integrations that will be fully recognized by OTel-compatible observability products and services.
 
-OpenTelemetry logging is today mostly structured when instrumentation libraries are used. However, most of the logs which exist today are generated by software, hardware, and cloud services which the user cannot control. OpenTelemetry provides a limited set of "reference integrations" to structure logs: primarily the [OpenTelemetry Collector Kubernetes Events Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/k8seventsreceiver) and an example of a regexp based parsing of Tomcat access logs with OpenTelemetry Collector File Receiver ([here](https://github.com/open-telemetry/opentelemetry-log-collection/blob/30807b96b2f0771e7d11452ebf98fe5e211ed6d7/examples/tomcat/config.yaml#L20)).
+OpenTelemetry logging is today mostly structured when instrumentation libraries are used. However, most of the logs which exist today are generated by software, hardware, and cloud services which the user cannot control. OpenTelemetry provides a limited set of "reference integrations" to structure logs: primarily the [OpenTelemetry Collector Kubernetes Events Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/k8seventsreceiver) and an example of a regular expression based parsing of Tomcat access logs with OpenTelemetry Collector File Receiver ([here](https://github.com/open-telemetry/opentelemetry-log-collection/blob/30807b96b2f0771e7d11452ebf98fe5e211ed6d7/examples/tomcat/config.yaml#L20)).
 By expanding the OTel semantic conventions with further namespaces already defined in ECS, a broader coverage of such mappings from different sources can be defined and implemented in the OTel collector.
 This, for example, includes logs from network appliances (mapping to the `network` and `interface` namespaces in ECS).
 
@@ -71,7 +71,7 @@ The coverage of ECS is very broad including in depth support for logs, security,
 ECS has the following guiding principles:
 
 * ECS favors human readability in order to enable broader adoption as many fields can be understood without having to read up their meaning in the reference,
-* ECS events include metadata to enable correlations across any dimension (host, data center, docker image, ip address...),
+* ECS events include metadata to enable correlations across any dimension (host, data center, Docker image, ip address...),
   * ECS does not differentiate the metadata fields that are specific to each event of the event source and the metadata that is shared by all the events of the source in the way OTel does, which differentiates between Resource Attributes and Log/Span/Metrics Attributes,
 * ECS groups fields in namespaces in order to:
   * Offer consistency and readability,
@@ -83,7 +83,7 @@ ECS has the following guiding principles:
 
 ### Example of a log message structured with ECS: NGINX access logs
 
-Example of a Nginx Access Log entry structured with ECS
+Example of a NGINX Access Log entry structured with ECS
 
 ```json
 {
@@ -161,7 +161,7 @@ Example of a Nginx Access Log entry structured with ECS
 | Category | <a href="../specification/logs/data-model.md#log-and-event-record-definition">OTel Logs and Event Record</a> (all or a subset of <a href="https://protobuf.dev/programming-guides/proto3/">GRPC data types</a>) | <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/field-data-types">ECS Data Types</a> |
 | --- | --- | --- |
 | Text | string | <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/text#text-field-type">text</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/text#match-only-text-field-type">match_only_text</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/keyword#keyword-field-type">keyword</a> <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/keyword#constant-keyword-field-type">constant_keyword</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/keyword#wildcard-field-type">wildcard</a> |
-| Dates | uint64 nanoseconds since Unix epoch | <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/date">date</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/date_nanos">date_nanos</a> |
+| Dates | uint64 nanoseconds since UNIX epoch | <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/date">date</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/date_nanos">date_nanos</a> |
 | Numbers | number | <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/number">long</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/number">double</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/number">scaled_float</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/boolean">boolean</a>… |
 | Objects | uint32, uint64… | <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/object">object</a> (JSON object), <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/flattened">flattened</a> (An entire JSON object as a single field value) |
 | Structured Objects | No complex semantic data type specified for the moment (e.g. string is being used for ip addresses rather than having an "ip" data structure in OTel). <br/> Note that OTel supports arrays and nested objects. | <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/ip">ip</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/geo-point">geo_point</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/geo-shape">geo_shape</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/version">version</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/range">long_range</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/range">date_range</a>, <a href="https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/range">ip_range</a> |
@@ -185,7 +185,7 @@ As the markdown code of the tables is hard to read and maintain with very long l
    </td>
   </tr>
   <tr>
-   <td><a href="../specification/logs/data-model.md#log-and-event-record-definition">Timestamp</a> (uint64 nanoseconds since Unix epoch)
+   <td><a href="../specification/logs/data-model.md#log-and-event-record-definition">Timestamp</a> (uint64 nanoseconds since UNIX epoch)
    </td>
    <td><a href="https://www.elastic.co/docs/reference/ecs/ecs-base#field-timestamp">@timestamp</a> (date)
    </td>
@@ -280,7 +280,7 @@ Prometheus is a de facto standard for observability metrics and OpenTelemetry al
 
 It would be useful to get interoperability between metrics collected by [official Prometheus exporters](https://prometheus.io/docs/instrumenting/exporters/) (e.g. the [Node/system metrics exporter](https://github.com/prometheus/node_exporter) or the [MySQL server exporter](https://github.com/prometheus/mysqld_exporter)) and their equivalent OpenTelemetry Collector receivers (e.g. OTel Collector [Host Metrics Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/hostmetricsreceiver) or [MySQL Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/mysqlreceiver)).
 
-Note that one of the challenges with Prometheus metrics naming conventions is that these are implicit conventions defined by each integration author which doesn't enable correlation due to the lack of consistency across integrations. For example, this inconsistency increases the complexity that an end-user has to deal with when configuring and monitoring alerts.
+Note that one of the challenges with Prometheus metrics naming conventions is that these are implicit conventions defined by each integration author which doesn't enable correlation due to the lack of consistency across integrations. For example, this inconsistency increases the complexity that an end user has to deal with when configuring and monitoring alerts.
 
 Prometheus' conventions are restricted to the style of the name of the metrics (see [Prometheus Metric and label naming](https://prometheus.io/docs/practices/naming/)) but don't specify unified metric names.
 
diff --git a/oteps/0201-scope-attributes.md b/oteps/0201-scope-attributes.md
index d9aebae793b..855a169c441 100644
--- a/oteps/0201-scope-attributes.md
+++ b/oteps/0201-scope-attributes.md
@@ -47,7 +47,7 @@ The following is the summary of proposed changes:
   with emitted telemetry.
 ```
 
-Since the attributes are optional this is a backwards compatible change.
+Since the attributes are optional this is a backward compatible change.
 
 We will modify the following clause:
 
@@ -69,7 +69,7 @@ It is unspecified whether or under which conditions the same or different
 ```
 
 Since we are defining more precisely previously undefined behavior this is a
-backwards compatible change.
+backward compatible change.
 
 #### Meter
 
@@ -130,7 +130,7 @@ message InstrumentationScope {
 }
 ```
 
-This change is backwards compatible from OTLP's interoperability perspective. Recipients
+This change is backward compatible from OTLP's interoperability perspective. Recipients
 of old OTLP versions will not see the Scope attributes and will ignore them, which we
 consider acceptable from interoperability perspective. This is aligned with our general
 stance on what happens when telemetry sources _add_ new data which old recipients
diff --git a/oteps/0202-events-and-logs-api.md b/oteps/0202-events-and-logs-api.md
index 2b371a449dc..99ee79328b4 100644
--- a/oteps/0202-events-and-logs-api.md
+++ b/oteps/0202-events-and-logs-api.md
@@ -6,7 +6,7 @@ We introduce an Events and Logs API that is based on the OpenTelemetry Log signa
 
 In OpenTelemetry's perspective Log Records and Events are different names for the same concept - however, there is a subtle difference in how they are represented using the underlying data model that is described below. We will describe why the existing Logging APIs are not sufficient for the purpose of creating events.  It will then be evident that we will need an API in OpenTelemetry for creating events. Note that the Events here refer to standalone Events and not to be confused with Span Events which occur only in the context of a span.
 
-The Logs part of the API introduced here is supposed to be used only by the Log Appenders and end-users should continue to use the logging APIs available in the languages.
+The Logs part of the API introduced here is supposed to be used only by the Log Appenders and end users should continue to use the logging APIs available in the languages.
 
 ### Subtle differences between Logs and Events
 
@@ -18,7 +18,7 @@ Here are a few situations that require recording of Events, there will be more.
 
 - RUM events (Client-side instrumentation)
   - Standalone events that occur when there is no span in progress, such as errors, user interaction events and web vitals.
-- Recording kubernetes events
+- Recording Kubernetes events
 - Collector Entity events [link](https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/edit)
 - Few other event systems described in [example mappings](../specification/logs/data-model-appendix.md#appendix-a-example-mappings) in the data model.
 
@@ -31,7 +31,7 @@ Here are a few situations that require recording of Events, there will be more.
 - The current Log APIs do not have a standard way to pass event attributes.
   - It may be possible to use the interpolation string args as the parameter to pass event attributes. However, the logging spec seems to map the human readable message (which is obtained after replacing the args in the interpolated string) to the Body field of LogRecord.
   - Log4j has an EventLogger interface that can be used to create structured messages with arbitrary key-value pairs, but log4j is not commonly used in Android apps as it is not officially supported on Android as per this [Stack Overflow thread](https://stackoverflow.com/a/60407849) by one of log4j’s maintainers.
-  - In Python, logging.LogRecord's extra field is mapped to Otel LogRecord's attributes but this field is a hidden field and not part of the public interface.
+  - In Python, logging.LogRecord's extra field is mapped to OTel LogRecord's attributes but this field is a hidden field and not part of the public interface.
 - The current Log APIs have a message parameter which could map to the Body field of LogRecord. However, this is restricted to String messages and does not allow for structured logs.
 
 For the above reasons we can conclude that we will need an API for creating Events.
@@ -58,11 +58,11 @@ For the Events and Logs API, it will be very similar to the Trace API. There wil
 
 ## Trade-offs and mitigations
 
-There could be confusion on whether the Logs part of the API is end-user callable. While it can eventually be used in the languages that do not have a popular logging library, it is not recommended to be used in the languages where there are other popular logging libraries and APIs and this fact must emphasized in different forums.
+There could be confusion on whether the Logs part of the API is end user callable. While it can eventually be used in the languages that do not have a popular logging library, it is not recommended to be used in the languages where there are other popular logging libraries and APIs and this fact must emphasized in different forums.
 
 ## Prior art and alternatives
 
-For client-side instrumentation, it was suggested initially that we use 0-duration spans to represent Events to get the benefit of Spans providing causality. For example, Splunk's RUM sdk for Android implements Events using [0-duration span](https://github.com/signalfx/splunk-otel-android/blob/3ca8584632f334671fdb6eaa09199ce01961787f/splunk-otel-android/src/main/java/com/splunk/rum/SplunkRum.java#L213). However, 0-duration spans are confusing and not consistent with standalone Events in other domains which are represented using `LogRecord`s.  Hence, for consistency reasons it will be good to use `LogRecord`s for standalone Events everywhere. To address the requirement of modeling causality between Events, we can create wrapper spans linked to the `LogRecord`s.
+For client-side instrumentation, it was suggested initially that we use 0-duration spans to represent Events to get the benefit of Spans providing causality. For example, Splunk's RUM SDK for Android implements Events using [0-duration span](https://github.com/signalfx/splunk-otel-android/blob/3ca8584632f334671fdb6eaa09199ce01961787f/splunk-otel-android/src/main/java/com/splunk/rum/SplunkRum.java#L213). However, 0-duration spans are confusing and not consistent with standalone Events in other domains which are represented using `LogRecord`s.  Hence, for consistency reasons it will be good to use `LogRecord`s for standalone Events everywhere. To address the requirement of modeling causality between Events, we can create wrapper spans linked to the `LogRecord`s.
 
 ## Open questions
 
@@ -70,5 +70,5 @@ None.
 
 ## Future possibilities
 
-1. As noted in the `Trade-offs and mitigation` section, we could allow the API to be used by end-users in the languages that do not have a popular logging library.
+1. As noted in the `Trade-offs and mitigation` section, we could allow the API to be used by end users in the languages that do not have a popular logging library.
 2. There is a possibility that we may want to record the Span Events using `LogRecord`s in future. In this case, they will be correlated wth the Spans using the `TraceId` and `SpanId` fields of the `LogRecord`. If this is desired, we may add a configuration option to the `TracerProvider` to create LogRecords for the Span Events.
diff --git a/oteps/0225-configuration.md b/oteps/0225-configuration.md
index e0e5653a865..b635e036aa5 100644
--- a/oteps/0225-configuration.md
+++ b/oteps/0225-configuration.md
@@ -15,7 +15,7 @@ The environment variable interface suffers from the following identified limitat
   * Configuring views.
   * Configuring arguments for parent based sampler (sampler parent is remote and sampled vs. not sampled, sampler when parent is local and sampled vs. not sampled).
 * **Runtime dependent**. Different systems expose this interface differently (Linux, BSD, Windows). This usually means unique instructions are required to properly interact with the configuration interface on different systems.
-* **Limited values**. Many systems only allow string values to be used, but OpenTelemetry specifies many configuration values other than this type. For example, OTEL_RESOURCE_ATTRIBUTES specifies a list of key value pairs to be used as resource attributes, but there is no way to specify array values, or indicate that the value should be interpreted as non-string type.
+* **Limited values**. Many systems only allow string values to be used, but OpenTelemetry specifies many configuration values other than this type. For example, OTEL_RESOURCE_ATTRIBUTES specifies a list of key-value pairs to be used as resource attributes, but there is no way to specify array values, or indicate that the value should be interpreted as non-string type.
 * **Limited validation**. Validation can only be performed by the receiver, there is no meta-configuration language to validate input.
 * **Lacks versioning**. The lack of versioning support for environment variables prevents evolution over time.
 
@@ -41,7 +41,7 @@ Using a configuration model or configuration file, users can configure all optio
 
 ## Internal details
 
-The schema for OpenTelemetry configuration is to be published in a repository to allow language implementations to leverage that definition to automatically generate code and/or validate end-user configuration. This will ensure that all implementations provide a consistent experience for any version of the schema they support. An example of such a proposed schema is available [here](./assets/0225-schema.json).
+The schema for OpenTelemetry configuration is to be published in a repository to allow language implementations to leverage that definition to automatically generate code and/or validate end user configuration. This will ensure that all implementations provide a consistent experience for any version of the schema they support. An example of such a proposed schema is available [here](./assets/0225-schema.json).
 
 The working group proposes the use of [JSON Schema](https://json-schema.org/) as the language to define the schema. It provides:
 
@@ -119,7 +119,7 @@ Create a `Configurer` from a [configuration model](#configuration-model).
 
 #### Get TracerProvider, MeterProvider, LoggerProvider
 
-Interpret the [configuration model](#configuration-model) and return SDK TracerProvider, MeterProvider, LoggerProvider which strictly reflect the configuration object's details and ignores the [opentelemetry environment variable configuration scheme](../specification/configuration/sdk-environment-variables.md).
+Interpret the [configuration model](#configuration-model) and return SDK TracerProvider, MeterProvider, LoggerProvider which strictly reflect the configuration object's details and ignores the [OpenTelemetry environment variable configuration scheme](../specification/configuration/sdk-environment-variables.md).
 
 ### Configuration model
 
@@ -299,7 +299,7 @@ In choosing to recommend JSON schema, the working group looked at the following
 * [Cue](https://cuelang.org/) - A promising simpler language to define a schema, the working group decided against CUE because:
   * Tooling available for validating CUE files in languages outside of Go were limited.
   * Familiarity and learning curve would create problems for both users and contributors of OpenTelemetry.
-* [Protobuf](https://protobuf.dev) - With protobuf already used heavily in OpenTelemetry, the format was worth investigating as an option to define the schema. The working group decided against Protobuf because:
+* [Protobuf](https://protobuf.dev) - With protobuf already used heavily in OpenTelemetry, the format was worth investigating as an option to define the schema. The working group decided against protobuf because:
   * Validation errors are the result of serialization errors which can be difficult to interpret.
   * Limitations in the schema definition language result in poor ergonomics if type safety is to be retained.
 
@@ -309,7 +309,7 @@ In choosing to recommend JSON schema, the working group looked at the following
 
 How should the SDK be configured when both no-code configuration (either environment variable or file config) and programmatic configuration are present? NOTE: this question exists today with only the environment variable interface available.
 
-* Solution 1: Make it clear that interpretation of the environment shouldn’t be built into components. Instead, SDKs should have a component that explicitly interprets the environment and returns a configured instance of the SDK. This is how the java SDK works today and it nicely separates concerns.
+* Solution 1: Make it clear that interpretation of the environment shouldn’t be built into components. Instead, SDKs should have a component that explicitly interprets the environment and returns a configured instance of the SDK. This is how the Java SDK works today and it nicely separates concerns.
 
 ### What is the exact configuration file format to use?
 
@@ -363,9 +363,9 @@ pip install opentelemetry-instrumentation
 opentelemetry-instrument --config ./config.yaml ./python/app.py
 ```
 
-#### OpAmp
+#### OpAMP
 
-The configuration may be used in the future in conjunction with the OpAmp protocol to make remote configuration of SDKs available as a feature supported by OpenTelemetry.
+The configuration may be used in the future in conjunction with the OpAMP protocol to make remote configuration of SDKs available as a feature supported by OpenTelemetry.
 
 ## Related Spec issues address
 
diff --git a/oteps/0227-separate-semantic-conventions.md b/oteps/0227-separate-semantic-conventions.md
index d0bc611b10c..a4f4d324904 100644
--- a/oteps/0227-separate-semantic-conventions.md
+++ b/oteps/0227-separate-semantic-conventions.md
@@ -37,11 +37,11 @@ moved, with documentation denoting the move, but preserving previous contents.
 Additionally, if the semantic conventions eventually move to domain-specific
 directory structure (e.g. `docs/{domain}/README.md`, with trace, metrics, events
 in the same file), then this can be refactored in the new repository, preserving
-git history.
+Git history.
 
 There will also be the following exceptions in the specification:
 
-- Semantic conventions used to implement API/SDK details will be fully specified in the `opentelemetry-specification` repo
+- Semantic conventions used to implement API/SDK details will be fully specified in the `opentelemetry-specification` repository
   and will not be allowed to change in the Semantic Convention directory.
   - Error/Exception handling will remain in the specification.
   - SDK configuration interaction w/ semantic convention will remain in the
@@ -81,7 +81,7 @@ seamlessly moved to their new location. This process lists steps in order:
 - Semantic conventions in the Specification will be marked as moved with
   links to the new location.
   - The semconv YAML files in the specification repository *will be deleted*.
-  - All semconv markdown files will be updated such that:
+  - All semconv Markdown files will be updated such that:
     - They no longer generate from YAML files.
     - They include a header denoting deprecation and move to the new repository.
 - Instrumentation authors will update their code generation to pull from the new
diff --git a/oteps/0232-maturity-of-otel.md b/oteps/0232-maturity-of-otel.md
index ac93aab8bcc..6525b6a8ffc 100644
--- a/oteps/0232-maturity-of-otel.md
+++ b/oteps/0232-maturity-of-otel.md
@@ -17,7 +17,7 @@ Quite often, the community is faced with the question of the quality and maturit
 Deliverables of a SIG MUST have a declared maturity level, established by SIG maintainers (SIGs), likely with the input of the code owners. While the main deliverable can have a specific maturity level, individual components might have a different one. Examples:
 
 * the Collector core distribution might declare itself stable and include a receiver that is not stable. In that case, the receiver has to be clearly marked as such
-* the Java Agent might be declared stable, while individual instrumentation packages are not
+* the Java agent might be declared stable, while individual instrumentation packages are not
 
 Components SHOULD NOT be marked as stable if their user-visible interfaces are not stable. For instance, if the Collector's component `otlpreceiver` declares a dependency on the OpenTelemetry Collector API "config" package which is marked with a maturity level of "beta", the `otlpreceiver` should be at most "beta". Maintainers are free to deviate from this recommendation if they believe users are not going to be affected by future changes.
 
@@ -59,7 +59,7 @@ This OTEP allows SIG maintainers to declare the maturity of the SIG's deliverabl
 
 * The specification status has a ["Component Lifecycle"](https://opentelemetry.io/docs/specs/status/) description, with definitions that might overlap with some of the levels listed in this OTEP.
 * The same page lists the status of the different parts of the spec
-* The ["Versioning and stability for OpenTelemetry clients"](https://opentelemetry.io/docs/specs/otel/versioning-and-stability/#signal-lifecycle) page has a detailed view on the lifecycle of a signal and which general stability guarantees should be expected by OpenTelemetry clients. Notably, it lacks information about maturity of the Collector. This OTEP could be seen as clashing with the last section of that page, "OpenTelemetry GA". But while that page established a point where both OpenTracing and OpenCensus would be considered deprecated, this OTEP here defines the criteria for calling OpenTelemetry "stable" and making that a requirement for a future graduation. This would also make it clear to end-users which parts of the project they can rely on.
+* The ["Versioning and stability for OpenTelemetry clients"](https://opentelemetry.io/docs/specs/otel/versioning-and-stability/#signal-lifecycle) page has a detailed view on the lifecycle of a signal and which general stability guarantees should be expected by OpenTelemetry clients. Notably, it lacks information about maturity of the Collector. This OTEP could be seen as clashing with the last section of that page, "OpenTelemetry GA". But while that page established a point where both OpenTracing and OpenCensus would be considered deprecated, this OTEP here defines the criteria for calling OpenTelemetry "stable" and making that a requirement for a future graduation. This would also make it clear to end users which parts of the project they can rely on.
 * The OpenTelemetry Collector has its own [stability levels](https://github.com/open-telemetry/opentelemetry-collector#stability-levels), which served as inspiration to the ones here.
 * [Definition of documentation states](https://opentelemetry.io/docs/specs/otel/document-status/)
 * [Telemetry stability](https://opentelemetry.io/docs/specs/otel/telemetry-stability/) (uses unstable instead of experimental)
@@ -67,7 +67,7 @@ This OTEP allows SIG maintainers to declare the maturity of the SIG's deliverabl
 ## Open questions
 
 * Should SDKs be required to fully implement the specification before they can be marked as stable? See [open-telemetry/community#2097](https://github.com/open-telemetry/community/issues/2097)
-* Should this OTEP define a file name to be adopted by all repositories to declare their deliverables and their maturity levels?
+* Should this OTEP define a filename to be adopted by all repositories to declare their deliverables and their maturity levels?
 
 ## Future possibilities
 
diff --git a/oteps/0243-app-telemetry-schema-vision-roadmap.md b/oteps/0243-app-telemetry-schema-vision-roadmap.md
index b6c7e985ada..445662e4120 100644
--- a/oteps/0243-app-telemetry-schema-vision-roadmap.md
+++ b/oteps/0243-app-telemetry-schema-vision-roadmap.md
@@ -58,13 +58,13 @@ But this approach is not without challenges:
 * **Performance overheads**: A significant downside of generic telemetry
   instrumentation is the various overheads it generally introduces due to inherent
   layers of abstraction. For example, the collection of attributes is typically
-  represented as a list of key/value pairs or as hashmaps, resulting in memory
-  overhead. A simple struct or a set of well-typed function arguments will be more
+  represented as a list of key-value pairs or as hashmaps, resulting in memory
+  overhead. A simple struct or a set of well-typed function parameters will be more
   efficient and less error-prone for representing this list of attributes. In the
   same way, it is possible to use a dictionary encoding for values whose domain is
   specified in the form of an enumeration in the schema definition.
 
-Databases and RPC systems (e.g., Protobuf & gRPC) have already addressed some of
+Databases and RPC systems (e.g., protobuf & gRPC) have already addressed some of
 these issues with a schema-first approach. There is nothing to prevent adopting
 a similar approach in the context of telemetry. **This document discusses how to
 apply a schema-first approach in the OpenTelemetry project and its implications
@@ -383,5 +383,5 @@ of the Resolved Telemetry Schema.
 ## Links
 
 - [Positional Paper: Schema-First Application Telemetry](https://research.facebook.com/publications/positional-paper-schema-first-application-telemetry/)
-- [A benchmark to understand the role of knowledge graphs on Large Language Model's accuracy for question answering on enterprise sql databases](https://arxiv.org/pdf/2311.07509#:~:text=The%20results%20of%20the%20benchmark%20provide%20evidence%20that%20supports%20our,LLM%20without%20a%20Knowledge%20Graph)
+- [A benchmark to understand the role of knowledge graphs on Large Language Model's accuracy for question answering on enterprise SQL databases](https://arxiv.org/pdf/2311.07509#:~:text=The%20results%20of%20the%20benchmark%20provide%20evidence%20that%20supports%20our,LLM%20without%20a%20Knowledge%20Graph)
 - [MetricFlow framework](https://docs.getdbt.com/docs/build/about-metricflow)
diff --git a/oteps/0258-env-context-baggage-carriers.md b/oteps/0258-env-context-baggage-carriers.md
index a680a7e77b3..1482b793816 100644
--- a/oteps/0258-env-context-baggage-carriers.md
+++ b/oteps/0258-env-context-baggage-carriers.md
@@ -210,7 +210,7 @@ Environment variable names used by the utilities in the Shell and Utilities
 (underscore) from the characters defined in Portable Character Set. Other
 characters may be permitted by an implementation; applications must tolerate
 the presence of such names. Upper-case and lower-case letters retain their
-unique identities and are not folded together. The name space of environment
+unique identities and are not folded together. The namespace of environment
 variable names containing lower-case letters is reserved for applications.
 Applications can define any environment variables with names from this name
 space without modifying the behaviour of the standard utilities.
@@ -232,7 +232,7 @@ this [documentation][cpython-doc] was added to clarify the behavior.
 ### Allowed characters
 
 To ensure compatibility, specification for Environment Variables SHOULD adhere
-to the current specification for `TextMapPropagator` where key/value pairs MUST
+to the current specification for `TextMapPropagator` where key-value pairs MUST
 only consist of US-ASCII characters that make up valid HTTP header fields as
 per RFC 7230.
 
diff --git a/oteps/0266-move-oteps-to-spec.md b/oteps/0266-move-oteps-to-spec.md
index 4acd721b646..d58345758d7 100644
--- a/oteps/0266-move-oteps-to-spec.md
+++ b/oteps/0266-move-oteps-to-spec.md
@@ -33,11 +33,11 @@ maintainers of the specification, this should not change the bar for acceptance.
 
 The following changes would occur:
 
-- The following files would be moved to the specification repo:
+- The following files would be moved to the specification repository:
   - `text/` directory -> `oteps/text/`
   - `0000-template.md` -> `oteps/0000-template.md`
 - Update the specification `Makefile` to include linting, spell checking, link checking and TOC-ing the oteps directory.
-- A one-time cleanup of OTEP markdown upon import to the specification repository.
+- A one-time cleanup of OTEP Markdown upon import to the specification repository.
 - Close existing OTEP PRs and ask folks to reopen against the specification repository.
 - New labels within the specification repository to tag OTEPs, including automation to set these on PR open.
 - Updating contributing guidelines to include a section about OTEPs.
@@ -63,6 +63,6 @@ What are the important portions of the OTEP process to bring over? Have we misse
 
 ## Future possibilities
 
-In the future, we could figure out how to make OTEPs more searchable, discoverable and highlighted within the opentelemetry.io website.
+In the future, we could figure out how to make OTEPs more searchable, discoverable and highlighted within the opentelemetry.io site.
 
 Additionally, we can look at extending staleness deadlines for OTEP labeled PRs.
diff --git a/oteps/4430-span-event-api-deprecation-plan.md b/oteps/4430-span-event-api-deprecation-plan.md
index 61e49f7bfdd..ba29391507b 100644
--- a/oteps/4430-span-event-api-deprecation-plan.md
+++ b/oteps/4430-span-event-api-deprecation-plan.md
@@ -116,7 +116,7 @@ OpenTelemetry zero-code distribution (if one exists for the language).
 
 ### Via the Collector
 
-Note: this is a nice-to-have only and not required for any other part
+Note: this is a nice to have only and not required for any other part
 of the Span Event API deprecation plan.
 
 This mechanism MAY be implemented as follows:
diff --git a/oteps/README.md b/oteps/README.md
index 2ddc38f3071..ec1250cee2a 100644
--- a/oteps/README.md
+++ b/oteps/README.md
@@ -55,21 +55,21 @@ For example, an OTEP proposing configurable sampling *and* various samplers shou
 
 ### Writing an OTEP
 
-- First, [fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo) this repo.
+- First, [fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo) this repository.
 - Copy [`0000-template.md`](./0000-template.md) to `0000-my-OTEP.md`, where `my-OTEP` is a title relevant to your proposal, and `0000` is the OTEP ID.
   Leave the number as is for now. Once a Pull Request is made, update this ID to match the PR ID.
 - Fill in the template. Put care into the details: It is important to present convincing motivation, demonstrate an understanding of the design's impact, and honestly assess the drawbacks and potential alternatives.
 
 ### Submitting the OTEP
 
-- An OTEP is `proposed` by posting it as a PR. Once the PR is created, update the OTEP file name to use the PR ID as the OTEP ID.
+- An OTEP is `proposed` by posting it as a PR. Once the PR is created, update the OTEP filename to use the PR ID as the OTEP ID.
 - An OTEP is `approved` when four reviewers github-approve the PR. The OTEP is then merged.
 - If an OTEP is `rejected` or `withdrawn`, the PR is closed. Note that these OTEPs submissions are still recorded, as GitHub retains both the discussion and the proposal, even if the branch is later deleted.
 - If an OTEP discussion becomes long, and the OTEP then goes through a major revision, the next version of the OTEP can be posted as a new PR, which references the old PR. The old PR is then closed. This makes OTEP review easier to follow and participate in.
 
 ### Integrating the OTEP into the Spec
 
-- Once an OTEP is `approved`, an issue is created in this repo to integrate the OTEP into the actual spec.
+- Once an OTEP is `approved`, an issue is created in this repository to integrate the OTEP into the actual spec.
 - When reviewing the spec PR for the OTEP, focus on whether the spec is written clearly, and reflects the changes approved in the OTEP. Please abstain from relitigating the approved OTEP changes at this stage.
 - An OTEP is `integrated` when four reviewers github-approve the spec PR. The PR is then merged, and the spec is versioned.
 
diff --git a/oteps/entities/0256-entities-data-model.md b/oteps/entities/0256-entities-data-model.md
index 8fe55806e5b..874736e3203 100644
--- a/oteps/entities/0256-entities-data-model.md
+++ b/oteps/entities/0256-entities-data-model.md
@@ -9,7 +9,7 @@ transferred, stored and interpreted by an entity observability system.
 - [Motivation](#motivation)
 - [Design Principles](#design-principles)
 - [Data Model](#data-model)
-  * [Minimally Sufficient Id](#minimally-sufficient-id)
+  * [Minimally Sufficient ID](#minimally-sufficient-id)
   * [Examples of Entities](#examples-of-entities)
 - [Entity Events](#entity-events)
   * [EntityState Event](#entitystate-event)
@@ -33,7 +33,7 @@ transferred, stored and interpreted by an entity observability system.
   * [Classes of Entity Types](#classes-of-entity-types)
   * [Multiple Observers](#multiple-observers)
   * [Is Type part of Entity's identity?](#is-type-part-of-entitys-identity)
-  * [Choosing from Multiple Ids](#choosing-from-multiple-ids)
+  * [Choosing from Multiple IDs](#choosing-from-multiple-ids)
 - [Future Work](#future-work)
 - [References](#references)
 
@@ -151,15 +151,15 @@ conventions</a> for attributes.
    </tr>
 </table>
 
-### Minimally Sufficient Id
+### Minimally Sufficient ID
 
 Commonly, a number of attributes of an entity are readily available for the telemetry
-producer to compose an Id from. Of the available attributes the entity Id should
+producer to compose an ID from. Of the available attributes the entity ID should
 include the minimal set of attributes that is sufficient for uniquely identifying
 that entity. For example
 a Process on a host can be uniquely identified by (`process.pid`,`process.start_time`)
-attributes. Adding for example `process.executable.name` attribute to the Id is
-unnecessary and violates the Minimally Sufficient Id rule.
+attributes. Adding for example `process.executable.name` attribute to the ID is
+unnecessary and violates the Minimally Sufficient ID rule.
 
 ### Examples of Entities
 
@@ -239,7 +239,7 @@ container.name
    </tr>
 </table>
 
-See more examples showing nuances of Id field composition in the
+See more examples showing nuances of ID field composition in the
 [Entity Identification](#entity-identification) section.
 
 ## Entity Events
@@ -324,7 +324,7 @@ emit a new EntityState event with a fresh timestamp and full list of
 values of all other fields.
 
 Entity event producers SHOULD periodically emit events even
-if the entity does not change. In this case the Type, Id and Attribute
+if the entity does not change. In this case the Type, ID and Attribute
 fields will remain the same, but a fresh Timestamp will be recorded in
 the event. Producing such events allows the system to be resilient to
 event losses. Even if some events are lost eventually the correct state
@@ -380,13 +380,13 @@ events as a liveliness indicator).
 
 The expiration mechanism is based on the previously reported `Interval` field of
 EntityState event. The recipient can use this value to compute when to expect the next
-EntityState event and if the event does not arrive in a timely manner (plus some slack)
+EntityState event and if the event does not arrive in a timely manner (plus some tolerance)
 it can consider the entity to be gone even if the EntityDelete event was not observed.
 
 ## Entity Identification
 
-The data model defines the structure of the entity Id field. This section explains
-how the Id field is computed.
+The data model defines the structure of the entity ID field. This section explains
+how the ID field is computed.
 
 ### LID, GID and IDCONTEXT
 
@@ -408,7 +408,7 @@ Where `IDCONTEXT(E)` is the identification context in which the LID of entity E
 The value of `IDCONTEXT(E)` is an entity itself, and thus we can compute the GID value of it too.
 
 In other words, the GID of an entity is a union of its LID and the GID of its
-identification context. Note: GID(E) is a map of key/value attributes.
+identification context. Note: GID(E) is a map of key-value attributes.
 
 The enrichment process often is responsible for determining the value of `IDCONTEXT(E)`
 and for computing the GID according to the formula defined above, although the GID may
@@ -421,7 +421,7 @@ OpenTelemetry semantic conventions will be enhanced to include entity definition
 well-known entities such as Service, Process, Host, etc.
 
 For well-known entity types LID(E) is defined in OTel semantic conventions per
-entity type. The value of LID is a map of key/value attributes. For example,
+entity type. The value of LID is a map of key-value attributes. For example,
 for entity of type "process" the semantic conventions define LID as 2 attributes:
 
 ```json5
@@ -431,7 +431,7 @@ for entity of type "process" the semantic conventions define LID as 2 attributes
 }
 ```
 
-For custom entity types (not defined in OTel semantic conventions) the end-user is
+For custom entity types (not defined in OTel semantic conventions) the end user is
 responsible for defining their custom semantic conventions in a similar way.
 
 The entity information producer is responsible for determining the identification
@@ -489,8 +489,8 @@ and Collector will use "host" as the IDCONTEXT and add host's LID to it:
 }
 ```
 
-If we assume that we have only one data center and host ids are globally
-unique then the above id is globally unique and is the GID of the
+If we assume that we have only one data center and host IDs are globally
+unique then the above ID is globally unique and is the GID of the
 process. If this assumption is not valid in our situation we would
 continue applying additional IDCONTEXT's until the GID is globally
 unique. See for example the
@@ -567,7 +567,7 @@ arrive to it in a different way:
 #### Host in Cloud Account
 
 A host running in a cloud account (e.g. AWS) will have a LID that uses
-the host instance id, unique within a single cloud account, e.g.:
+the host instance ID, unique within a single cloud account, e.g.:
 
 ```json5
 {
@@ -578,7 +578,7 @@ the host instance id, unique within a single cloud account, e.g.:
 
 OTel Collector with
 [resourcedetection](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/resourcedetectionprocessor)
-processor with "aws" detector enabled will add the IDCONTEXT of the
+processor with "AWS" detector enabled will add the IDCONTEXT of the
 cloud account like this:
 
 ```json5
@@ -619,12 +619,12 @@ that implements entity event emitting for `k8scluster` receiver in the Collector
 
 Alternative proposals were made [here](https://docs.google.com/document/d/1PLPSAnWvFWCsm6meAj6OIVDBvxsk983V51WugF0NgVo/edit) and  
 [here](https://docs.google.com/document/d/1bLmkQSv35Fi6Wbe4bAqQ-_JS7XWIXWbvuirVmAkz4a4/edit)
-to use a different structure for entity Id field.
+to use a different structure for entity ID field.
 
-We rejected these proposals in favour of the Id field proposed in this OTEP for the
+We rejected these proposals in favour of the ID field proposed in this OTEP for the
 following reasons:
 
-- The map of key/value attributes is widely used elsewhere in OpenTelemetry as
+- The map of key-value attributes is widely used elsewhere in OpenTelemetry as
   Resource attributes, as Scope attributes, as Metric datapoint attributes, etc. so
   it is conceptually consistent with the rest of OTel.
 
@@ -684,7 +684,7 @@ There are a couple of reasons:
 The data model requires the Attributes field to use the extended
 [any](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.44.0/specification/logs/data-model.md#type-any)
 attribute values, that allows more complex data types. This is different from the data
-type used by the Id field, which is more restricted in the shape.
+type used by the ID field, which is more restricted in the shape.
 
 Are we happy with this discrepancy?
 
@@ -723,7 +723,7 @@ an "ObserverId" field. EntityState event will then look like this:
 |Timestamp|nanoseconds|
 |Interval|milliseconds|
 |Type||
-|Id||
+|ID||
 |Attributes||
 |ObserverId|string or bytes|
 
@@ -737,22 +737,22 @@ Here is corresponding
 
 ### Is Type part of Entity's identity?
 
-Is the Type field part of the entity's identity together with the Id field?
+Is the Type field part of the entity's identity together with the ID field?
 
 For example let's assume we have a Host and an OTel Collector running on the Host.
-The Host's Id will contain one attribute: `host.id`, and the Type of the entity will be
+The Host's ID will contain one attribute: `host.id`, and the Type of the entity will be
 "host". The Collector technically speaking can be also identified by one attribute
 `host.id` and the Type of the entity will be "otel.collector". This only works if we
 consider the Type field to be part of the entity's identity.
 
 If the Type field is not part of identity then in the above example we require that the
-entity that describes the Collector has some other attribute in its Id (for example
+entity that describes the Collector has some other attribute in its ID (for example
 `agent.type` attribute [if it gets accepted](https://github.com/open-telemetry/semantic-conventions/pull/950)).
 
 Here is corresponding
 [TODO item](https://github.com/orgs/open-telemetry/projects/85?pane=issue&itemId=57053320).
 
-### Choosing from Multiple Ids
+### Choosing from Multiple IDs
 
 Sometimes the same entity may be identified in more than one way. For example a Pod can
 be identified by its `k8s.pod.uid` but it can be also identified by a pair of
diff --git a/oteps/entities/0264-resource-and-entities.md b/oteps/entities/0264-resource-and-entities.md
index 0cd055b79da..4d8f7e623f3 100644
--- a/oteps/entities/0264-resource-and-entities.md
+++ b/oteps/entities/0264-resource-and-entities.md
@@ -29,7 +29,7 @@ It is an expansion on the [previous entity proposal](0256-entities-data-model.md
   * [Resource detectors (soon to be entity detectors) need to be composable / disjoint](#resource-detectors-soon-to-be-entity-detectors-need-to-be-composable--disjoint)
   * [New entities added by extension should not break existing code](#new-entities-added-by-extension-should-not-break-existing-code)
   * [Navigational attributes need to exist and can be used to identify an entity but could be augmented with UUID or other aspects. - Having ONLY a UUID for entity identification is not good enough](#navigational-attributes-need-to-exist-and-can-be-used-to-identify-an-entity-but-could-be-augmented-with-uuid-or-other-aspects---having-only-a-uuid-for-entity-identification-is-not-good-enough)
-  * [Collector augmentation / enrichment (resource, e.g.) - Should be extensible and not hard-coded. We need a general algorithm not specific rulesets](#collector-augmentation--enrichment-resource-eg---should-be-extensible-and-not-hard-coded-we-need-a-general-algorithm-not-specific-rulesets)
+  * [Collector augmentation / enrichment (resource, e.g.) - Should be extensible and not hardcoded. We need a general algorithm not specific rulesets](#collector-augmentation--enrichment-resource-eg---should-be-extensible-and-not-hardcoded-we-need-a-general-algorithm-not-specific-rulesets)
   * [Users are expected to provide / prioritize "detectors" and determine which entity is "producing" or most-important for a signal](#users-are-expected-to-provide--prioritize-detectors-and-determine-which-entity-is-producing-or-most-important-for-a-signal)
   * [For an SDK - ALL telemetry should be associated with the same set of entities (resource labels)](#for-an-sdk---all-telemetry-should-be-associated-with-the-same-set-of-entities-resource-labels)
 - [Open Questions](#open-questions)
@@ -42,7 +42,7 @@ It is an expansion on the [previous entity proposal](0256-entities-data-model.md
   * [What happens if existing Resource translation in the collector remove resource attributes an Entity relies on?](#what-happens-if-existing-resource-translation-in-the-collector-remove-resource-attributes-an-entity-relies-on)
   * [What about advanced entity interaction in the Collector?](#what-about-advanced-entity-interaction-in-the-collector)
 - [Trade-offs and mitigations](#trade-offs-and-mitigations)
-  * [Why don't we download schema url contents?](#why-dont-we-download-schema-url-contents)
+  * [Why don't we download schema URL contents?](#why-dont-we-download-schema-url-contents)
 - [Prior art and alternatives](#prior-art-and-alternatives)
 - [Future Possibilities](#future-possibilities)
 - [Use Cases](#use-cases)
@@ -85,7 +85,7 @@ We define the following SDK components:
 
 #### Resource Provider
 
-The SDK Resource Provider is responsible for running all configured Resource and Entity Detectors.  There will be some (user-controlled, otel default) priority order to these.
+The SDK Resource Provider is responsible for running all configured Resource and Entity Detectors.  There will be some (user-controlled, OTel default) priority order to these.
 
 - The Resource Provider will detect conflicts in Entity of the same type being discovered and choose one to use.
 - When using Entity Detectors and Resource detectors together, the following merge rules will be used:
@@ -99,7 +99,7 @@ The SDK Resource Provider is responsible for running all configured Resource and
 
 #### Entity Detector
 
-The Entity detector in the SDK is responsible for detecting possible entities that could identify the SDK (called "associated entities"). For Example, if the SDK is running in a kubernetes pod, it may provide an Entity for that pod. SDK Entity Detectors are only required to provide identifying attributes, but may provide descriptive attributes to ensure combined Resource contains similar attributes as today's SDK.
+The Entity detector in the SDK is responsible for detecting possible entities that could identify the SDK (called "associated entities"). For Example, if the SDK is running in a Kubernetes pod, it may provide an Entity for that pod. SDK Entity Detectors are only required to provide identifying attributes, but may provide descriptive attributes to ensure combined Resource contains similar attributes as today's SDK.
 
 An Entity Detector would have an API similar to:
 
@@ -162,7 +162,7 @@ The actual design for this ENV variable interaction would follow the approval of
 
 ### Interactions with OpenTelemetry Collector
 
-The OpenTelemetry collector can be updated to optionally  interact with Entity on Resource. A new entity-focused resource detection process can be created which allows add/override behavior at the entity level, rather than individual attribute level.
+The OpenTelemetry Collector can be updated to optionally  interact with Entity on Resource. A new entity-focused resource detection process can be created which allows add/override behavior at the entity level, rather than individual attribute level.
 
 For example, the existing resource detector looks like this:
 
@@ -189,7 +189,7 @@ The list of detectors is given in priority order (first wins, in event of a tie,
 
 The rules for attributes would follow entity merging rules, as defined for the SDK resource provider.
 
-Note: While this proposals shows a new processor replacing the `resourcedetection` processor, the details of whether to modify-in-place the existing `resourcedetection` processor or create a new one would be determined as a follow up to this design. Ideally, we don't want users to need new configuration for resource in the otel collector.
+Note: While this proposals shows a new processor replacing the `resourcedetection` processor, the details of whether to modify-in-place the existing `resourcedetection` processor or create a new one would be determined as a follow up to this design. Ideally, we don't want users to need new configuration for resource in the OTel collector.
 
 ## Datamodel Changes
 
@@ -207,7 +207,7 @@ The following changes are made:
 | ----- | ---- | ----------- | ------- |
 | schema_url | string | The Schema URL, if known. This is the identifier of the Schema that the resource data  is recorded in.  This field is deprecated and should no longer be used. | Will be deprecated |
 | dropped_attributes_count | integer | dropped_attributes_count is the number of dropped attributes. If the value is 0, then no attributes were dropped. | Unchanged |
-| attributes | repeated KeyValue | Set of attributes that describe the resource.<br/><br/>Attribute keys MUST be unique (it is not allowed to have more than one attribute with the same key). | Unchanged |
+| attributes | repeated key-value | Set of attributes that describe the resource.<br/><br/>Attribute keys MUST be unique (it is not allowed to have more than one attribute with the same key). | Unchanged |
 | entities | repeated ResourceEntityRef | Set of entities that participate in this Resource. | Added |
 
 The DataModel would ensure that attributes in Resource are produced from both the identifying and descriptive attributes of Entity.  This does not mean the protocol needs to transmit duplicate data, that design is TBD.
@@ -220,7 +220,7 @@ The entityref data model, would have the following changes from the original [en
 | ----- | ---- | ----------- | ------- |
 | schema_url | string | The Schema URL, if known. This is the identifier of the Schema that the entity data  is recorded in. To learn more about Schema URL ([see docs](https://opentelemetry.io/docs/specs/otel/schemas/#schema-url)) | added |
 | type | string | Defines the type of the entity. MUST not change during the lifetime of the entity. For example: "service" or "host". This field is required and MUST not be empty for valid entities. | unchanged |
-| identifying_attributes_keys | repeated string | Attribute Keys that identify the entity.<br/>MUST not change during the lifetime of the entity. The Id must contain at least one attribute.<br/><br/>These keys MUST exists in Resource.attributes.<br/><br/>Follows OpenTelemetry common attribute definition. SHOULD follow OpenTelemetry semantic conventions for attributes. | now a reference |
+| identifying_attributes_keys | repeated string | Attribute Keys that identify the entity.<br/>MUST not change during the lifetime of the entity. The ID must contain at least one attribute.<br/><br/>These keys MUST exists in Resource.attributes.<br/><br/>Follows OpenTelemetry common attribute definition. SHOULD follow OpenTelemetry semantic conventions for attributes. | now a reference |
 | descriptive_attributes_keys | repeated string | Descriptive (non-identifying) attribute keys of the entity.<br/>MAY change over the lifetime of the entity. MAY be empty. These attribute keys are not part of entity's identity.<br/><br/>These keys MUST exist in Resource.attributes.<br/><br/>Follows any value definition in the OpenTelemetry spec - it can be a scalar value, byte array, an array or map of values. Arbitrary deep nesting of values for arrays and maps is allowed.<br/><br/>SHOULD follow OpenTelemetry semantic conventions for attributes. | now a reference |
 
 ### Resource Identity
@@ -277,14 +277,14 @@ Users will need to configure a new Entity detector for new entities being modell
 
 Resource will still be composed of identifying and descriptive attributes of Entity, allowing baseline navigational attributes users already expect from resource.
 
-### Collector augmentation / enrichment (resource, e.g.) - Should be extensible and not hard-coded. We need a general algorithm not specific rulesets
+### Collector augmentation / enrichment (resource, e.g.) - Should be extensible and not hardcoded. We need a general algorithm not specific rulesets
 
 The concept of "Entity" is a new definition for Resource.  Where previously, resource was a collection of attributes and users would interact with each
 individually, now there is a "bundle" of attributes called an Entity.  Entities have an identity and descriptions, and the collector is able to
 identify conflicts against the set of attributes that make up an Entity.
 
 The merge rules defined here give precedent for the collector to generically interact with "type", "identifying attributes" and "descriptive attributes"
-rather than hard-coded rules that have to understand the nuance of when `host.id` influences `host.name`, e.g.
+rather than hardcoded rules that have to understand the nuance of when `host.id` influences `host.name`, e.g.
 
 ### Users are expected to provide / prioritize "detectors" and determine which entity is "producing" or most-important for a signal
 
@@ -306,7 +306,7 @@ Going forward, we have set of options:
 
 - Duplicate attributes in `Entity` section of Resource.
 - Reference attributes of Resource in entity.
-- Only identify Entity id and keep attribute<->entity association out of band.
+- Only identify Entity ID and keep attribute<->entity association out of band.
 - Extend Attribute on Resource so that we can track the entity type per Key-Value (across any attribute in OTLP).
 
 The third option prevents generic code from interacting with Resource and Entity without understanding the model of each.  The first keeps all usage of entity simple at the expense of duplicating information and the middle is awkward to interact with from an OTLP usage perspective. The fourth is violates our stability policy for OTLP.
@@ -348,7 +348,7 @@ These designs will be explored and evaluated in light of the requirements. For n
 
 ### Should entities have a domain?
 
-Is it worth having a `domain` in addition to type for entity?  We could force each entity to exist in one domain and leverage domain generically in resource management.  Entity Detectors would be responsible for an entire domain, selecting only ONE to apply a resource. Domains could be layered, e.g. a Cloud-specific domain may layer on top of a Kubernetes domain, where "GKE cluster entity" identifies *which* kubernetes cluster a kubernetes infra entity is part of.  This layer would be done naively, via automatic join of participating entities or explicit relationships derived from GKE specific hooks.
+Is it worth having a `domain` in addition to type for entity?  We could force each entity to exist in one domain and leverage domain generically in resource management.  Entity Detectors would be responsible for an entire domain, selecting only ONE to apply a resource. Domains could be layered, e.g. a Cloud-specific domain may layer on top of a Kubernetes domain, where "GKE cluster entity" identifies *which* Kubernetes cluster a Kubernetes infra entity is part of.  This layer would be done naively, via automatic join of participating entities or explicit relationships derived from GKE specific hooks.
 
 It's unclear if this is needed initially, and we believe this could be layered in later.
 
@@ -357,7 +357,7 @@ It's unclear if this is needed initially, and we believe this could be layered i
 Given the problems leading to the Entities working group, and the needs of existing Resource users today, we think it is infeasible and un-scalable to limit resource to only one entity.  This would place restrictions on modeling Entities that would require OpenTelemetry to be the sole source of entity definitions and hurt building an open and extensible ecosystem.  Additionally it would need careful definition of solutions for the following problems/rubrics:
 
 - New entities added by extension should not break existing code
-- Collector augmentation / enrichment (resource, e.g.) - Should be extensible and not hard-coded. We need a general algorithm not specific rulesets.
+- Collector augmentation / enrichment (resource, e.g.) - Should be extensible and not hardcoded. We need a general algorithm not specific rulesets.
 
 ### What identity should entities use (LID, UUID / GUID, or other)?
 
@@ -375,7 +375,7 @@ While we expect the collector to be the first component to start engaging with E
 
 ### What about advanced entity interaction in the Collector?
 
-One problem that motivated this design is the issue of "local resource detection" vs. "remote signal collection" in the OpenTelemetry collector.  That is, I have a process running on a machine writing to an OpenTelemetry
+One problem that motivated this design is the issue of "local resource detection" vs. "remote signal collection" in the OpenTelemetry Collector.  That is, I have a process running on a machine writing to an OpenTelemetry
 collector running on a different machine.  The current `resourcedetectionprocessor` in the collector appends attributes to resource based on discovering *where the collector is running*.  However,
 as the collector could determine that telemetry has come from a different machine, it could also avoid adding resource attributes that are not relevant to incoming data.
 
@@ -386,7 +386,7 @@ resource based on more advanced knowledge of the communication protocol used to
 
 The design proposed here attempts to balance non-breaking (backwards and forwards compatible) changes with the need to improve problematic issues in the Specification.  Given the inability of most SDKs to implement the current Resource merge specification, breaking this should have little effect on actual users.  Instead, the proposed merge specification should allow implementations to match current behavior and expectation, while evolving for users who engage with the new model.
 
-### Why don't we download schema url contents?
+### Why don't we download schema URL contents?
 
 OpenTelemetry needs to work in environments that have no/limited access to the external internet. We entertained, and
 dismissed merging solutions that *require* access to the contents of `schema_url` to work. While the core algorithm
@@ -439,14 +439,14 @@ flowchart LR
 
 Here, there is a service running on Google Compute Engine. The user
 has configured a Google Cloud specific set of entity detectors.  Both the
-built in OpenTelemetry detection and the configured Google Cloud detection
+built-in OpenTelemetry detection and the configured Google Cloud detection
 discover a `host` entity.
 
 The following outcome would occur:
 
 - The resulting resource would have all of the following entities: `host`, `process`, `service` and `gcp.gce`
-- The user-configured resource detector would take priority over built in: the `host` defined from the Google Cloud detection would "win" and be included in resource.
-  - This means `host.id` e.g. could be the id discovered for GCE VMs.  Similarly for other cloud provider detection, like Amazon EC2 where VMs are given a unique ID by the Cloud Provider, rather than a generic machine ID, e.g.
+- The user-configured resource detector would take priority over built-in: the `host` defined from the Google Cloud detection would "win" and be included in resource.
+  - This means `host.id` e.g. could be the ID discovered for GCE VMs.  Similarly for other cloud provider detection, like Amazon EC2 where VMs are given a unique ID by the Cloud Provider, rather than a generic machine ID, e.g.
   - This matches existing behavior/expectations today for AWS, GCP, etc. on what `host.id` would mean.
 - Users would be able to configure which host wins, by swapping the priority order of "default" vs. cloud-specific detection.
 
@@ -476,7 +476,7 @@ The resulting OTLP from the collector would contain a resource with all
 of the entities (`process`, `service`, `ec2`, and `host`).  This is because
 the entities are all disjoint.
 
-*Note: this matches today's behavior of existing resource detection and OpenTelemetry collector where all attributes wind up on resource.*
+*Note: this matches today's behavior of existing resource detection and OpenTelemetry Collector where all attributes wind up on resource.*
 
 ### SDK and Collector - Entity coordination with descriptive attributes
 
@@ -602,7 +602,7 @@ Ideally, we'd like a solution where:
     - `host.cpu.cache.l2.size`
     - `os.description`
     - `os.type`
-  - [docker](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/internal/docker/metadata.yaml)
+  - [Docker](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/internal/docker/metadata.yaml)
     - `host.name`
     - `os.type`
   - [heroku](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/internal/heroku/metadata.yaml)
@@ -614,7 +614,7 @@ Ideally, we'd like a solution where:
     - `service.instance.id`
     - `service.name`
     - `service.version`
-  - [gcp](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/internal/gcp/metadata.yaml)
+  - [GCP](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/internal/gcp/metadata.yaml)
     - gke
       - `cloud.provider`
       - `cloud.platform`
@@ -702,7 +702,7 @@ Ideally, we'd like a solution where:
     - `host.id`
     - `host.name`
     - *exploded consul metadata*
-  - k8s Node
+  - K8s Node
     - `k8s.node.uid`
   - Openshift
     - `cloud.provider`
@@ -780,10 +780,10 @@ Ideally, we'd like a solution where:
       - `process.command_line`
       - `process.command_args`
       - `process.owner`
-    - [builtin](https://github.com/open-telemetry/opentelemetry-go/blob/main/sdk/resource/builtin.go)
+    - [built-in](https://github.com/open-telemetry/opentelemetry-go/blob/main/sdk/resource/builtin.go)
       - `service.instance.id`
       - `service.name`
-- [OTEL operator](https://github.com/open-telemetry/opentelemetry-operator/blob/a1e8f927909b81eb368c0483940e0b90d7fdb057/pkg/instrumentation/sdk_test.go#L752) injected ENV variables
+- [OTel operator](https://github.com/open-telemetry/opentelemetry-operator/blob/a1e8f927909b81eb368c0483940e0b90d7fdb057/pkg/instrumentation/sdk_test.go#L752) injected ENV variables
   - `service.instance.id`
   - `service.name`
   - `service.version`
@@ -803,7 +803,7 @@ AWS, Azure, GCP, Heroku, etc. all provide the following "bundles" of resource:
 - `host.*`, when relevant
 - `k8s.cluster.*`, when relevant
 - `service.*` when relevant
-- `container.*` for a subset of k8s providers
+- `container.*` for a subset of K8s providers
 
 "system" detection provides the following:
 
@@ -817,7 +817,7 @@ SDK specific detection provides the following:
 - `sdk.*`
 - `service.*`
 
-The OTEL operator for k8s provides the following via ENV variables:
+The OTel operator for K8s provides the following via ENV variables:
 
 - `k8s.namespace.*`
 - `k8s.node.*`
@@ -827,20 +827,20 @@ The OTEL operator for k8s provides the following via ENV variables:
 
 ### What could this mean for choosing entities that belong on resource?
 
-Let's look at an example of a container running in kubernetes, specifically EKS.
+Let's look at an example of a container running in Kubernetes, specifically EKS.
 
-If the OTEL operator, the SDK and the collector are all used, the following
+If the OTel operator, the SDK and the collector are all used, the following
 attributes will wind up on resource:
 
-- `service.*` - from SDK and otel operator
+- `service.*` - from SDK and OTel operator
 - `sdk.*` - from SDK
 - `process.*` - from SDK
 - `host.*` - Note: from system detector on collector
 - `container.*` - from EKS detector on SDK
-- `k8s.namespace.*` - from otel operator
-- `k8s.node.*` - from otel operator
-- `k8s.pod.*` - from otel operator
-- `k8s.container.*` - from otel operator
+- `k8s.namespace.*` - from OTel operator
+- `k8s.node.*` - from OTel operator
+- `k8s.pod.*` - from OTel operator
+- `k8s.container.*` - from OTel operator
 - `k8s.cluster.*` - from EKS detector on SDK or collector
 - `cloud.*` - from EKS detector on SDK or collector
 
diff --git a/oteps/entities/4665-multiple-resource-in-sdk.md b/oteps/entities/4665-multiple-resource-in-sdk.md
index 8a314f0d522..f9ead5a3fa2 100644
--- a/oteps/entities/4665-multiple-resource-in-sdk.md
+++ b/oteps/entities/4665-multiple-resource-in-sdk.md
@@ -15,7 +15,7 @@ OpenTelemetry needs to address two fundamental problems:
 The first problem is well outlined in (not accepted) [OTEP 4316](https://github.com/open-telemetry/opentelemetry-specification/pull/4316).
 Fundamentally, while we need an immutable identity, the reality is that `Resource`
 in today's OpenTelemetry usage is not strong enough to support key use cases. For example,
-OpenTelemetry JS, in the node.js environment, cannot guarantee that all identifying
+OpenTelemetry JS, in the Node.js environment, cannot guarantee that all identifying
 attributes for Resource are discovered prior to SDK startup, leading to an "eventual identity" situation
 that must be addressed in the Specification. Additionally, our Client/Browser SIG has been
 trying to model the notion of "User Session" which has a much shorter lifespan than the SDK itself, so
@@ -24,7 +24,7 @@ requiring a single identity that is both immutable and matches the SDK lifetime
 However, [OTEP 4316](https://github.com/open-telemetry/opentelemetry-specification/pull/4316) explores
 relaxing the immutability restriction vs. providing a new mechanism. During prototyping,
 initially this seemed to be easily accomplished, but ran into major complications both in interactions
-with OpAmp (where a stable identity for the SDK is desired), and in designing a Metrics SDK, where
+with OpAMP (where a stable identity for the SDK is desired), and in designing a Metrics SDK, where
 changes in Resource mean a dynamic and divergent storage strategy, without a priori knowledge of whether these resource mutations are
 relevant to the metric or not.
 
@@ -146,7 +146,7 @@ implicit View definition, and we leverage metric advice to allow sending
 attributes than is naturally used when reporting the metric.
 
 As called out in the description, [OTEP 4316](https://github.com/open-telemetry/opentelemetry-specification/pull/4316)
-proposes making resource fully mutable, which comes with its own set of tradeoffs.
+proposes making resource fully mutable, which comes with its own set of trade-offs.
 
 Today, Semantic Conventions already defines `Entity` and uses it to group and
 report `Resource` attributes cohesively. Additionally, Semantic convention only
diff --git a/oteps/logs/0091-logs-vocabulary.md b/oteps/logs/0091-logs-vocabulary.md
index 4cb9aeb6719..5e9246344b0 100644
--- a/oteps/logs/0091-logs-vocabulary.md
+++ b/oteps/logs/0091-logs-vocabulary.md
@@ -40,7 +40,7 @@ object, in the [Events](../../specification/trace/api.md#add-events) list.
 
 ### Log Attributes
 
-Key/value pairs contained in a `Log Record`.
+Key-value pairs contained in a `Log Record`.
 
 ### Structured Logs
 
diff --git a/oteps/logs/0092-logs-vision.md b/oteps/logs/0092-logs-vision.md
index 72b906623e0..1826a9a5e79 100644
--- a/oteps/logs/0092-logs-vision.md
+++ b/oteps/logs/0092-logs-vision.md
@@ -87,7 +87,7 @@ We will produce guidelines on how legacy applications can emit logs in a
 manner that makes them compatible with OpenTelemetry's approach and enables
 telemetry data correlation. We will also have a reasonable story around
 logs that are emitted by sources over which we may have no control and which
-emit logs in pre-defined formats via pre-defined mediums (e.g. flat file logs,
+emit logs in predefined formats via predefined mediums (e.g. flat file logs,
 Syslog, etc).
 
 We will have technical solutions or guidelines for using popular logging
@@ -120,7 +120,7 @@ legacy applications which may not emit Spans at all.
 ## Legacy Use Cases
 
 Logging technology has a decades-long history. There exists a large number of
-logging libraries, collection agents, network protocols, open-source and
+logging libraries, collection agents, network protocols, open source and
 proprietary backends. We recognize this fact and aim to make our proposals in a
 manner that honours valid legacy use-cases, while at the same time suggests
 better solutions where they are due.
diff --git a/oteps/logs/0097-log-data-model.md b/oteps/logs/0097-log-data-model.md
index 312efbc38c4..66a43e3c326 100644
--- a/oteps/logs/0097-log-data-model.md
+++ b/oteps/logs/0097-log-data-model.md
@@ -117,7 +117,7 @@ fields:
 
 - Named top-level fields of specific type and meaning.
 
-- Fields stored in the key/value pair lists, which can contain arbitrary values
+- Fields stored in the key-value pair lists, which can contain arbitrary values
   of different types. The keys and values for well-known fields follow semantic
   conventions for key names and possible values that allow all parties that work
   with the field to have the same interpretation of the data. See references to
@@ -133,7 +133,7 @@ The reasons for having these 2 kinds of fields are:
 - Ability to enforce types of named fields, which is very useful for compiled
   languages with type checks.
 
-- Flexibility to represent less frequent data via key/value pair lists. This
+- Flexibility to represent less frequent data via key-value pair lists. This
   includes well-known data that has standardized semantics as well as arbitrary
   custom data that the application may want to include in the logs.
 
@@ -167,8 +167,8 @@ Here is the list of fields in a log record:
 | Field Name     | Description                                  |
 | -------------- | -------------------------------------------- |
 | Timestamp      | Time when the event occurred.                |
-| TraceId        | Request trace id.                            |
-| SpanId         | Request span id.                             |
+| TraceId        | Request trace ID.                            |
+| SpanId         | Request span ID.                             |
 | TraceFlags     | W3C trace flag.                              |
 | SeverityText   | The severity text (also known as log level). |
 | SeverityNumber | Numerical value of the severity.             |
@@ -181,7 +181,7 @@ Below is the detailed description of each field.
 
 ### Field: `Timestamp`
 
-Type: Timestamp, uint64 nanoseconds since Unix epoch.
+Type: Timestamp, uint64 nanoseconds since UNIX epoch.
 
 Description: Time when the event occurred measured by the origin clock. This
 field is optional, it may be missing if the timestamp is unknown.
@@ -192,16 +192,16 @@ field is optional, it may be missing if the timestamp is unknown.
 
 Type: byte sequence.
 
-Description: Request trace id as defined in
+Description: Request trace ID as defined in
 [W3C Trace Context](https://www.w3.org/TR/trace-context/#trace-id). Can be set
-for logs that are part of request processing and have an assigned trace id. This
+for logs that are part of request processing and have an assigned trace ID. This
 field is optional.
 
 #### Field: `SpanId`
 
 Type: byte sequence.
 
-Description: Span id. Can be set for logs that are part of a particular
+Description: Span ID. Can be set for logs that are part of a particular
 processing span. If SpanId is present TraceId SHOULD be also present. This field
 is optional.
 
@@ -401,7 +401,7 @@ occurrence of the event coming from the same source. This field is optional.
 
 ### Field: `Resource`
 
-Type: key/value pair list.
+Type: key-value pair list.
 
 Description: Describes the source of the log, aka
 [resource](../../specification/overview.md#resources).
@@ -418,7 +418,7 @@ This field is optional.
 
 ### Field: `Attributes`
 
-Type: key/value pair list.
+Type: key-value pair list.
 
 Description: Additional information about the specific event occurrence. "key"
 of each pair is a `string` and "value" is of `any` type. Unlike the `Resource`
@@ -552,32 +552,32 @@ drawbacks that do not make Syslog a serious contender for a data model:
 - While it allows structured attributes the body of the message can be only a
   string.
 
-- Severity is hard-coded to 8 possible numeric values, and does not allow custom
+- Severity is hardcoded to 8 possible numeric values, and does not allow custom
   severity texts.
 
 - Structured data does not allow arbitrary nesting and is 2-level only.
 
 - No clear separate place to specify data source (aka resource). There are a
-  couple hard-coded fields that serve this purpose in a limited way (HOSTNAME,
+  couple hardcoded fields that serve this purpose in a limited way (HOSTNAME,
   APP-NAME, FACILITY).
 
 ### Fluentd Forward Protocol Model
 
 [Forward protocol](https://github.com/fluent/fluentd/wiki/Forward-Protocol-Specification-v1)
 defines a log Entry concept as a timestamped record. The record consists of 2
-elements: a tag and a map of arbitrary key/value pairs.
+elements: a tag and a map of arbitrary key-value pairs.
 
 The model is universal enough to represent any log record. However, here are
 some drawbacks:
 
-- All attributes of a record are represented via generic key/value pairs (except
+- All attributes of a record are represented via generic key-value pairs (except
   tag and timestamp). This misses the optimization opportunities (see [Design
   Notes](#design-notes)).
 
 - There is no clear separate place to specify data source (aka resource).
 
 - There is no mention of how exactly keys should be named and what are expected
-  values. This lack of any naming convention or standardization of key/value
+  values. This lack of any naming convention or standardization of key-value
   pairs makes interoperability difficult.
 
 ## Appendix A. Example Mappings
@@ -609,7 +609,7 @@ this data model.
   <tr>
     <td>FACILITY</td>
     <td>enum</td>
-    <td>Describes where the event originated. A predefined list of Unix processes. Part of event source identity. Example: `mail system`</td>
+    <td>Describes where the event originated. A predefined list of UNIX processes. Part of event source identity. Example: `mail system`</td>
     <td>`Attributes["syslog.facility"]`</td>
   </tr>
   <tr>
@@ -1252,7 +1252,7 @@ It normally contains what the hostname command returns on the host machine.</td>
     <td>string</td>
     <td>Name of the host.
 
-It may contain what hostname returns on Unix systems, the fully qualified, or a name specified by the user. </td>
+It may contain what hostname returns on UNIX systems, the fully qualified, or a name specified by the user. </td>
 
 <td>`Resource["host.name"]`</td>
 
diff --git a/oteps/logs/0130-logs-1.0ga-definition.md b/oteps/logs/0130-logs-1.0ga-definition.md
index 9e42e50cbf5..d5f09b2dc33 100644
--- a/oteps/logs/0130-logs-1.0ga-definition.md
+++ b/oteps/logs/0130-logs-1.0ga-definition.md
@@ -59,5 +59,5 @@ GA (which will only include traces and metrics).
 
 - Implement an example that shows how to use OpenTelemetry Collector to collect
   correlated logs, traces and metrics from a distributed microservices
-  application (preferably running in a cloud-native control plane like
+  application (preferably running in a cloud native control plane like
   Kubernetes)
diff --git a/oteps/logs/0150-logging-library-sdk.md b/oteps/logs/0150-logging-library-sdk.md
index 2c7d4033406..2d679d4c2b9 100644
--- a/oteps/logs/0150-logging-library-sdk.md
+++ b/oteps/logs/0150-logging-library-sdk.md
@@ -22,7 +22,7 @@ successful prototypes first. This OTEP is first and foremost a specification and
 guidelines on how to create the prototypes.
 
 The specification defines how the OpenTelemetry Logging Library SDK exposes its
-functionality to authors of extensions to language-specific 3rd party logging
+functionality to authors of extensions to language-specific third-party logging
 libraries and to end users that want to produce logs in the
 [OpenTelemetry manner](../../specification/logs/README.md).
 
@@ -49,7 +49,7 @@ emit logs in OpenTelemetry formats.
 
 Note: The functionality that this document proposes will be an SDK package. A
 logging-related API package may be added in the future if we decide to have an
-end-user callable logging API. Until then the functions and methods callable
+end user callable logging API. Until then the functions and methods callable
 from this SDK package are intended to be used by Logging Libraries only and are
 NOT intended to be used by the end user and will NOT be exposed in the
 OpenTelemetry API package.
@@ -167,7 +167,7 @@ popular logging library.
 One of the possible approaches to emit and collect logs that OpenTelemetry
 supports is via intermediary files. When configuring the LogEmitterProvider,
 OTLP File exporter should be used to write logs to a file or stdout in either
-OTLP JSON or OTLP Protobuf binary format.
+OTLP JSON or OTLP protobuf binary format.
 
 ![Logging to File](images/otep0150/otlp-file.png)
 
@@ -256,7 +256,7 @@ user-facing logging API more complicated.
   
 ## Future possibilities
 
-In the future we may also add end-user callable OpenTelemetry Logging API
+In the future we may also add end user callable OpenTelemetry Logging API
 specification.
 
 ## References
diff --git a/oteps/metrics/0003-measure-metric-type.md b/oteps/metrics/0003-measure-metric-type.md
index 236a47f3d34..0a282a7754a 100644
--- a/oteps/metrics/0003-measure-metric-type.md
+++ b/oteps/metrics/0003-measure-metric-type.md
@@ -6,7 +6,7 @@ A working group convened on 8/21/2019 to discuss and debate the two metrics RFCs
 
 ## Overview
 
-Introduce a `Measure` kind of metric object that supports a `Record` API method.  Like existing `Gauge` and `Cumulative` metrics, the new `Measure` metric supports pre-defined labels.  A new `RecordBatch` measurement API  is introduced for recording multiple metric observations simultaneously.
+Introduce a `Measure` kind of metric object that supports a `Record` API method.  Like existing `Gauge` and `Cumulative` metrics, the new `Measure` metric supports predefined labels.  A new `RecordBatch` measurement API  is introduced for recording multiple metric observations simultaneously.
 
 ## Terminology
 
@@ -14,15 +14,15 @@ This RFC changes how "Measure" is used in the OpenTelemetry metrics specificatio
 
 Since this document will be read in the future after the proposal has been written, uses of the word "current" lead to confusion.  For this document, the term "preceding" refers to the state that was current prior to these changes.
 
-The preceding specification used the term `TimeSeries` to describe an instrument bound with a set of pre-defined labels.  In this document, [the term "Handle" is used to describe an instrument with bound labels](0009-metric-handles.md).  In a future OTEP this will be again changed to "Bound instrument".  The term "Handle" is used throughout this document to refer to a bound instrument.
+The preceding specification used the term `TimeSeries` to describe an instrument bound with a set of predefined labels.  In this document, [the term "Handle" is used to describe an instrument with bound labels](0009-metric-handles.md).  In a future OTEP this will be again changed to "Bound instrument".  The term "Handle" is used throughout this document to refer to a bound instrument.
 
 ## Motivation
 
-In the preceding `Metric.GetOrCreateTimeSeries` API for Gauges and Cumulatives, the caller obtains a `TimeSeries` handle for repeatedly recording metrics with certain pre-defined label values set.  This enables an important optimization for exporting pre-aggregated metrics, since the implementation is able to compute the aggregate summary "entry" using a pointer or fast table lookup. The efficiency gain requires that the aggregation keys be a subset of the pre-defined labels.
+In the preceding `Metric.GetOrCreateTimeSeries` API for Gauges and Cumulatives, the caller obtains a `TimeSeries` handle for repeatedly recording metrics with certain predefined label values set.  This enables an important optimization for exporting pre-aggregated metrics, since the implementation is able to compute the aggregate summary "entry" using a pointer or fast table lookup. The efficiency gain requires that the aggregation keys be a subset of the predefined labels.
 
-Application programs with long-lived objects and associated Metrics can take advantage of pre-defined labels by computing label values once per object (e.g., in a constructor), rather than once per call site. In this way, the use of pre-defined labels improves the usability of the API as well as makes an important optimization possible to the implementation.
+Application programs with long-lived objects and associated Metrics can take advantage of predefined labels by computing label values once per object (e.g., in a constructor), rather than once per call site. In this way, the use of predefined labels improves the usability of the API as well as makes an important optimization possible to the implementation.
 
-The preceding raw statistics API did not specify support for pre-defined labels.  This RFC replaces the raw statistics API by a new, general-purpose kind of metric, `MeasureMetric`, generally intended for recording individual measurements like the preceding raw statistics API, with explicit support for pre-defined labels.
+The preceding raw statistics API did not specify support for predefined labels.  This RFC replaces the raw statistics API by a new, general-purpose kind of metric, `MeasureMetric`, generally intended for recording individual measurements like the preceding raw statistics API, with explicit support for predefined labels.
 
 The preceding raw statistics API supported all-or-none recording for interdependent measurements using a common label set.  This RFC introduces a `RecordBatch` API to support recording batches of measurements in a single API call, where a `Measurement` is now defined as a pair of `MeasureMetric` and `Value` (integer or floating point).
 
@@ -63,7 +63,7 @@ Metric instruments are constructed through the `Meter` API. Constructing an inst
 
 See the specification for more information on these fields, including formatting and uniqueness requirements.  To define a new metric, use one of the `Meter` API methods (e.g., with names like `NewCumulativeMetric`, `NewGaugeMetric`, or `NewMeasureMetric`).
 
-Metric instrument Handles combine a metric instrument with a set of pre-defined labels.  Handles are obtained by calling a language-specific API method (e.g., `GetHandle`) on the metric instrument with certain label values.  Handles may be used to `Set()`, `Add()`, or `Record()` metrics according to their kind.
+Metric instrument Handles combine a metric instrument with a set of predefined labels.  Handles are obtained by calling a language-specific API method (e.g., `GetHandle`) on the metric instrument with certain label values.  Handles may be used to `Set()`, `Add()`, or `Record()` metrics according to their kind.
 
 ## Selecting Metric Kind
 
@@ -140,13 +140,13 @@ The batch measurement API uses a language-specific method name (e.g., `RecordBat
 
 ## Prior art and alternatives
 
-Prometheus supports the notion of vector metrics, which are those that support pre-defined labels for a specific set of required keys.  The vector-metric API supports a variety of methods like `WithLabelValues` to associate labels with a metric handle, similar to `GetHandle` in OpenTelemetry.  As in this proposal, Prometheus supports a vector API for all metric types.
+Prometheus supports the notion of vector metrics, which are those that support predefined labels for a specific set of required keys.  The vector-metric API supports a variety of methods like `WithLabelValues` to associate labels with a metric handle, similar to `GetHandle` in OpenTelemetry.  As in this proposal, Prometheus supports a vector API for all metric types.
 
 ## Open questions
 
 ### `GetHandle` argument ordering
 
-Argument ordering has been proposed as the way to pass pre-defined label values in `GetHandle`.  The argument list must match the parameter list exactly, and if it doesn't we generally find out at runtime or not at all.  This model has more optimization potential, but is easier to misuse than the alternative.  The alternative approach is to always pass label:value pairs to `GetOrCreateTimeseries`, as opposed to an ordered list of values.
+Argument ordering has been proposed as the way to pass predefined label values in `GetHandle`.  The argument list must match the parameter list exactly, and if it doesn't we generally find out at runtime or not at all.  This model has more optimization potential, but is easier to misuse than the alternative.  The alternative approach is to always pass label:value pairs to `GetOrCreateTimeseries`, as opposed to an ordered list of values.
 
 ### `RecordBatch` argument ordering
 
diff --git a/oteps/metrics/0008-metric-observer.md b/oteps/metrics/0008-metric-observer.md
index 4efc15a8ecf..f29a2523fe1 100644
--- a/oteps/metrics/0008-metric-observer.md
+++ b/oteps/metrics/0008-metric-observer.md
@@ -14,7 +14,7 @@ Gauge metric instruments are typically used to reflect properties that are pre-c
 
 Why are gauges different than cumulative and measure instruments?  Measure instruments, by definition, carry information in the individual event, so the callback cannot optimize any better than the SDK can in this case.  Cumulative instruments are more commonly used to record amounts that are readily available, such as the number of bytes read or written, and while this may not always be true, recall the special case of `NonDescending` gauges.
 
-`NonDescending` gauges owe their existence to this case, that we support non-negative cumulative metrics which, being expensive to compute, are recommended for use with `Observer` callbacks.  For example, if it requires a system call or more to compute a non-descending sum, such as the _cpu seconds_ consumed by the process, we should declare a non-descending gauge `Observer` for the instrument, instead of a cumulative.  This allows the cost of the metric to be reduced according to the desired monitoring frequency.
+`NonDescending` gauges owe their existence to this case, that we support non-negative cumulative metrics which, being expensive to compute, are recommended for use with `Observer` callbacks.  For example, if it requires a system call or more to compute a non-descending sum, such as the _CPU seconds_ consumed by the process, we should declare a non-descending gauge `Observer` for the instrument, instead of a cumulative.  This allows the cost of the metric to be reduced according to the desired monitoring frequency.
 
 One significant difference between gauges that are explicitly `Set()`, as compared with observer callbacks, is that `Set()` happens inside a context, whereas the observer callback does not.
 
diff --git a/oteps/metrics/0009-metric-handles.md b/oteps/metrics/0009-metric-handles.md
index a8370d5a335..a81386b30e9 100644
--- a/oteps/metrics/0009-metric-handles.md
+++ b/oteps/metrics/0009-metric-handles.md
@@ -4,7 +4,7 @@ Specify the behavior of the Metrics API "Handle" type, for efficient repeated-us
 
 ## Motivation
 
-The specification currently names this concept "TimeSeries", the type returned by `GetOrCreateTimeseries`, which supports binding a metric to a pre-defined set of labels for repeated use.  This proposal renames these "Handle" and `GetHandle`, respectively, and adds further detail to the API specification for handles.  
+The specification currently names this concept "TimeSeries", the type returned by `GetOrCreateTimeseries`, which supports binding a metric to a predefined set of labels for repeated use.  This proposal renames these "Handle" and `GetHandle`, respectively, and adds further detail to the API specification for handles.  
 
 ## Explanation
 
@@ -12,7 +12,7 @@ The `TimeSeries` is referred to as a "Handle", as the former name suggests an im
 
 Applications are encouraged to re-use metric handles for efficiency.
 
-Handles are useful to reduce the cost of repeatedly recording a metric instrument (cumulative, gauge, or measure) with a pre-defined set of label values.
+Handles are useful to reduce the cost of repeatedly recording a metric instrument (cumulative, gauge, or measure) with a predefined set of label values.
 
 `GetHandle` gets a new handle given a [`LabelSet`](./0049-metric-label-set.md).
 
diff --git a/oteps/metrics/0010-cumulative-to-counter.md b/oteps/metrics/0010-cumulative-to-counter.md
index 1b6bc95b1f8..0ee551d9fca 100644
--- a/oteps/metrics/0010-cumulative-to-counter.md
+++ b/oteps/metrics/0010-cumulative-to-counter.md
@@ -19,7 +19,7 @@ However, we have identified important sub-cases of Counter that are treated as f
 - True-cumulative Counter: By default, `Add()` arguments must be >= 0.
 - Bi-directional Counter: As an option, `Add()` arguments must be +/-0.
 
-Gauges are sometimes used to monitoring non-descending quantities (e.g., cpu usage), as an option:
+Gauges are sometimes used to monitoring non-descending quantities (e.g., CPU usage), as an option:
 
 - Bi-directional Gauge: By default, `Set()` arguments may by +/- 0.
 - Uni-directional Gauge: As an option, `Set()` arguments must change by >= 0.
diff --git a/oteps/metrics/0049-metric-label-set.md b/oteps/metrics/0049-metric-label-set.md
index 185d718dc34..f4a2a1bbec7 100644
--- a/oteps/metrics/0049-metric-label-set.md
+++ b/oteps/metrics/0049-metric-label-set.md
@@ -1,6 +1,6 @@
 # Metric `LabelSet` specification
 
-Introduce a first-class `LabelSet` API type as a handle on a pre-defined set of labels for the Metrics API.
+Introduce a first-class `LabelSet` API type as a handle on a predefined set of labels for the Metrics API.
 
 ## Motivation
 
@@ -12,7 +12,7 @@ The Metrics API supports three calling conventions: the Handle convention, the D
 
 ## Explanation
 
-Metric instrument APIs which presently take labels in the form `{ Key: Value, ... }` will be updated to take an explicit `LabelSet`.  The `Meter.Labels()` API method supports getting a `LabelSet` from the API, allowing the programmer to acquire a pre-defined label set.  Here are several examples of `LabelSet` re-use.  Assume we have two instruments:
+Metric instrument APIs which presently take labels in the form `{ Key: Value, ... }` will be updated to take an explicit `LabelSet`.  The `Meter.Labels()` API method supports getting a `LabelSet` from the API, allowing the programmer to acquire a predefined label set.  Here are several examples of `LabelSet` re-use.  Assume we have two instruments:
 
 ```golang
 var (
@@ -49,7 +49,7 @@ Of course, repeated calls to `Meter.RecordBatch()` could re-use a `LabelSet` as
 ### Ordered `LabelSet` option
 
 As a language-level decision, APIs may support _ordered_ LabelSet
-construction, in which a pre-defined set of ordered label keys is
+construction, in which a predefined set of ordered label keys is
 defined such that values can be supplied in order.  This allows a
 faster code path to construct the `LabelSet`.  For example,
 
diff --git a/oteps/metrics/0080-remove-metric-gauge.md b/oteps/metrics/0080-remove-metric-gauge.md
index 59055d22075..7674119fac0 100644
--- a/oteps/metrics/0080-remove-metric-gauge.md
+++ b/oteps/metrics/0080-remove-metric-gauge.md
@@ -89,7 +89,7 @@ There's a number that rises and falls such as a bank account balance.
 This was being `Set()` at the finish of all transactions.  Replace it
 with a Measure instrument and `Record()` the last value.
 
-Similar cases: report a cpu load, specific temperature, fan speed, or
+Similar cases: report a CPU load, specific temperature, fan speed, or
 altitude measurement associated with a request.
 
 ## Internal details
diff --git a/oteps/metrics/0088-metric-instrument-optional-refinements.md b/oteps/metrics/0088-metric-instrument-optional-refinements.md
index 6e3dd5aab85..721ee19856b 100644
--- a/oteps/metrics/0088-metric-instrument-optional-refinements.md
+++ b/oteps/metrics/0088-metric-instrument-optional-refinements.md
@@ -68,7 +68,7 @@ there are generally two relevant modes of aggregation:
 
 1. Within one collection interval, for one label set, the SDK's
 `Aggregator.Add()` interface method incorporates one new measurement
-value into the current aggregation value.  This happens at run time,
+value into the current aggregation value.  This happens at runtime,
 therefore is referred to as _temporal aggregation_.  This mode applies
 only to Measure instruments.
 2. Within one collection interval, when combining label sets, the
diff --git a/oteps/metrics/0090-remove-labelset-from-metrics-api.md b/oteps/metrics/0090-remove-labelset-from-metrics-api.md
index e6070d2d8fb..bf719d71527 100644
--- a/oteps/metrics/0090-remove-labelset-from-metrics-api.md
+++ b/oteps/metrics/0090-remove-labelset-from-metrics-api.md
@@ -8,7 +8,7 @@ capabilities).
 ## Motivation
 
 The [`LabelSet`](./0049-metric-label-set.md) API type was added to serve as a
-handle on a pre-defined set of labels for the Metrics API.
+handle on a predefined set of labels for the Metrics API.
 
 This API represents an optimization for the current metrics API that allows the
 implementations to avoid encoding and checking labels restrictions multiple
@@ -20,7 +20,7 @@ cleaner code and OpenTelemetry needs to address them as well, so this means that
 it is important for OpenTelemetry to support record APIs where users can pass
 directly the labels.
 
-OpenTelemetry can always add this optimization later (backwards compatible
+OpenTelemetry can always add this optimization later (backward compatible
 change) if we determine that it is very important to have.
 
 ## Trade-offs and mitigations
diff --git a/oteps/metrics/0126-Configurable-Metric-Aggregations.md b/oteps/metrics/0126-Configurable-Metric-Aggregations.md
index 2aa1707084d..e8f2aef52c4 100644
--- a/oteps/metrics/0126-Configurable-Metric-Aggregations.md
+++ b/oteps/metrics/0126-Configurable-Metric-Aggregations.md
@@ -29,12 +29,12 @@ of a "Views" API, but does not intend to implement the full View functionality f
 The basic API has two parts.
 
 * InstrumentSelector - Enables specifying the selection of one or more instruments for the configuration to apply to.
-  - Selection options include: the instrument type (Counter, ValueRecorder, etc), and a regex for instrument name.
+  - Selection options include: the instrument type (Counter, ValueRecorder, etc), and a regular expression for instrument name.
   - If more than one option is provided, they are considered additive.
   - Example: select all ValueRecorders whose name ends with ".duration".
 * View - configures how the batching and aggregation should be done.
   - 3 things can be specified: The aggregation (Sum, MinMaxSumCount, Histogram, etc), the "temporality" of the batching,
-    and a set of pre-defined labels to consider as the subset to be used for aggregations.
+    and a set of predefined labels to consider as the subset to be used for aggregations.
     - Note: "temporality" can be one of "DELTA" and "CUMULATIVE" and specifies whether the values of the aggregation
       are reset after a collection is done or not, respectively.
   - If not all are specified, then the others should be considered to be requesting the default.
diff --git a/oteps/metrics/0146-metrics-prototype-scenarios.md b/oteps/metrics/0146-metrics-prototype-scenarios.md
index ca2634122f1..9a903f6d059 100644
--- a/oteps/metrics/0146-metrics-prototype-scenarios.md
+++ b/oteps/metrics/0146-metrics-prototype-scenarios.md
@@ -170,38 +170,38 @@ Both libraries will provide out-of-box metrics, the metrics have two categories:
 
 #### Server Climate Control Library
 
-Note: the **Host Name** should leverage [`OpenTelemetry
+Note: the **Hostname** should leverage [`OpenTelemetry
 Resource`](../../specification/resource/sdk.md),
 so it should be covered by the metrics SDK rather than API, and strictly
 speaking it is not considered as a "dimension" from the SDK perspective.
 
 **Server temperature:**
 
-| Host Name | Temperature (F) |
-| --------- | --------------- |
-| MachineA  | 65.3            |
+| Hostname | Temperature (F) |
+| -------- | --------------- |
+| MachineA | 65.3            |
 
 Note: Temperature may take on negative values. For this reason, you must choose the instrument carefully to ensure it is one that
 can accept negative recordings and that they can be aggregated appropriately.
 
 **Server humidity:**
 
-| Host Name | Humidity (%) |
-| --------- | ------------ |
-| MachineA  | 21           |
+| Hostname | Humidity (%) |
+| -------- | ------------ |
+| MachineA | 21           |
 
 **Server CPU usage:**
 
-| Host Name | CPU usage (seconds) |
-| --------- | ------------------- |
-| MachineA  | 100.1               |
+| Hostname | CPU usage (seconds) |
+| -------- | ------------------- |
+| MachineA | 100.1               |
 
 **Server Memory usage:**
 
-| Host Name | Memory usage (bytes) |
-| --------- | -------------------- |
-| MachineA  | 1000000000           |
-| MachineA  | 2000000000           |
+| Hostname | Memory usage (bytes) |
+| -------- | -------------------- |
+| MachineA | 1000000000           |
+| MachineA | 2000000000           |
 
 #### HTTP Server Library
 
@@ -212,20 +212,20 @@ Baggage`](../../specification/baggage/api.md),
 strictly speaking it is not part of the metrics API, but it is considered as a
 "dimension" from the metrics SDK perspective.
 
-| Host Name | Process ID | Client Type | HTTP Method | HTTP Host | HTTP Flavor | Peer IP   | Peer Port | Host IP   | Host Port |
-| --------- | ---------- | ----------- | ----------- | --------- | ----------- | --------- | --------- | --------- | --------- |
-| MachineA  | 1234       | Android     | GET         | otel.org  | 1.1         | 127.0.0.1 | 51327     | 127.0.0.1 | 80        |
-| MachineA  | 1234       | Android     | POST        | otel.org  | 1.1         | 127.0.0.1 | 51328     | 127.0.0.1 | 80        |
-| MachineA  | 1234       | iOS         | PUT         | otel.org  | 1.1         | 127.0.0.1 | 51329     | 127.0.0.1 | 80        |
+| Hostname | Process ID | Client Type | HTTP Method | HTTP Host | HTTP Flavor | Peer IP   | Peer Port | Host IP   | Host Port |
+| -------- | ---------- | ----------- | ----------- | --------- | ----------- | --------- | --------- | --------- | --------- |
+| MachineA | 1234       | Android     | GET         | otel.org  | 1.1         | 127.0.0.1 | 51327     | 127.0.0.1 | 80        |
+| MachineA | 1234       | Android     | POST        | otel.org  | 1.1         | 127.0.0.1 | 51328     | 127.0.0.1 | 80        |
+| MachineA | 1234       | iOS         | PUT         | otel.org  | 1.1         | 127.0.0.1 | 51329     | 127.0.0.1 | 80        |
 
 **HTTP server request duration:**
 
 Note: the server duration is only available for **finished HTTP requests**.
 
-| Host Name | Process ID | Client Type | HTTP Method | HTTP Host | HTTP Status Code | HTTP Flavor | Peer IP   | Peer Port | Host IP   | Host Port | Duration (ms) |
-| --------- | ---------- | ----------- | ----------- | --------- | ---------------- | ----------- | --------- | --------- | --------- | --------- | ------------- |
-| MachineA  | 1234       | Android     | GET         | otel.org  | 200              | 1.1         | 127.0.0.1 | 51327     | 127.0.0.1 | 80        | 8.5           |
-| MachineA  | 1234       | Android     | POST        | otel.org  | 304              | 1.1         | 127.0.0.1 | 51328     | 127.0.0.1 | 80        | 100.0         |
+| Hostname | Process ID | Client Type | HTTP Method | HTTP Host | HTTP Status Code | HTTP Flavor | Peer IP   | Peer Port | Host IP   | Host Port | Duration (ms) |
+| -------- | ---------- | ----------- | ----------- | --------- | ---------------- | ----------- | --------- | --------- | --------- | --------- | ------------- |
+| MachineA | 1234       | Android     | GET         | otel.org  | 200              | 1.1         | 127.0.0.1 | 51327     | 127.0.0.1 | 80        | 8.5           |
+| MachineA | 1234       | Android     | POST        | otel.org  | 304              | 1.1         | 127.0.0.1 | 51328     | 127.0.0.1 | 80        | 100.0         |
 
 **HTTP active sessions:**
 
@@ -242,7 +242,7 @@ The application owner (developer Y) would only want the following metrics:
 * Server humidity - reported every minute
 * HTTP server request duration, reported every 5 seconds, with a subset of the
   dimensions:
-  * Host Name
+  * Hostname
   * HTTP Method
   * HTTP Host
   * HTTP Status Code
@@ -253,15 +253,15 @@ The application owner (developer Y) would only want the following metrics:
   * Total number of finished HTTP requests
   * Number of currently-in-flight HTTP requests (concurrent HTTP requests)
 
-  | Host Name | Process ID | HTTP Host | Received Requests | Finished Requests | Concurrent Requests |
-  | --------- | ---------- | --------- | ----------------- | ----------------- | ------------------- |
-  | MachineA  | 1234       | otel.org  | 630               | 601               | 29                  |
-  | MachineA  | 5678       | otel.org  | 1005              | 1001              | 4                   |
+  | Hostname | Process ID | HTTP Host | Received Requests | Finished Requests | Concurrent Requests |
+  | -------- | ---------- | --------- | ----------------- | ----------------- | ------------------- |
+  | MachineA | 1234       | otel.org  | 630               | 601               | 29                  |
+  | MachineA | 5678       | otel.org  | 1005              | 1001              | 4                   |
   
 * Exception samples (exemplar) - in case HTTP 5xx happened, developer Y would
-  want to see a sample request with trace id, span id and all the dimensions
+  want to see a sample request with trace ID, span ID and all the dimensions
   (IP, Port, etc.)
 
-  | Trace ID                         | Span ID          | Host Name | Process ID | Client Type | HTTP Method | HTTP Host | HTTP Status Code | HTTP Flavor | Peer IP   | Peer Port | Host IP   | Host Port | Exception            |
-  | -------------------------------- | ---------------- | --------- | ---------- | ----------- | ----------- | --------- | ---------------- | ----------- | --------- | --------- | --------- | --------- | -------------------- |
-  | 8389584945550f40820b96ce1ceb9299 | 745239d26e408342 | MachineA  | 1234       | iOS         | PUT         | otel.org  | 500              | 1.1         | 127.0.0.1 | 51329     | 127.0.0.1 | 80        | SocketException(...) |
+  | Trace ID                         | Span ID          | Hostname | Process ID | Client Type | HTTP Method | HTTP Host | HTTP Status Code | HTTP Flavor | Peer IP   | Peer Port | Host IP   | Host Port | Exception            |
+  | -------------------------------- | ---------------- | -------- | ---------- | ----------- | ----------- | --------- | ---------------- | ----------- | --------- | --------- | --------- | --------- | -------------------- |
+  | 8389584945550f40820b96ce1ceb9299 | 745239d26e408342 | MachineA | 1234       | iOS         | PUT         | otel.org  | 500              | 1.1         | 127.0.0.1 | 51329     | 127.0.0.1 | 80        | SocketException(...) |
diff --git a/oteps/profiles/0212-profiling-vision.md b/oteps/profiles/0212-profiling-vision.md
index 2cadd225986..7bb4f234463 100644
--- a/oteps/profiles/0212-profiling-vision.md
+++ b/oteps/profiles/0212-profiling-vision.md
@@ -16,7 +16,7 @@ This document and efforts thus far are motivated by:
 
 - This [long-standing issue](https://github.com/open-telemetry/oteps/issues/139)
   created in October 2020
-- A conversation about priorities at the in-person OpenTelemetry meeting at Kubecon EU
+- A conversation about priorities at the in-person OpenTelemetry meeting at KubeCon EU
   2022
 - Increasing community interest in profiling as an observability signal
   alongside logs, metrics, and traces
@@ -81,11 +81,11 @@ factors such as:
 
 - Language (and language runtime)
 - Profiler Type
-- Data type being profiled (i.e. cpu, memory, etc)
+- Data type being profiled (i.e. CPU, memory, etc)
 - Availability or utilization of symbolic information
 
 A fairly comprehensive taxonomy of various profiling formats can be found on the
-[profilerpedia website](https://profilerpedia.markhansen.co.nz/formats/).
+[profilerpedia site](https://profilerpedia.markhansen.co.nz/formats/).
 
 As a result of this variation, the tooling and collection of profiling data
 lacks in exactly the areas in which OpenTelemetry has built as its core
@@ -95,7 +95,7 @@ engineering values:
   language has different ways of collecting, sending, and storing profiling data
   and often with no regard to linking to other signals
 - Profiling currently lacks consistency: Currently profiling agents and formats
-  can change arbitrarily with no unified criteria for how to take end-users into
+  can change arbitrarily with no unified criteria for how to take end users into
   account
 
 ## Making profiling compatible with other signals
@@ -134,14 +134,14 @@ For existing profilers we will provide instructions on how these legacy formats
 can emit profiles in a manner that makes them compatible with OpenTelemetry’s
 approach and enables telemetry data correlation.
 
-Particularly for popular profilers such as the ones native to Golang and Java
+Particularly for popular profilers such as the ones native to Go and Java
 (JFR) we will help to have them produce OpenTelemetry-compatible profiles with
 minimal overhead.
 
 ## Performance considerations
 
 Profiling agents can be architected in a variety of differing ways, with
-reasonable trade offs made that may impact performance, completeness, accuracy
+reasonable trade-offs made that may impact performance, completeness, accuracy
 and so on. Similarly, the manner in which such a profiler might produce or
 consume OpenTelemetry-compatible data could vary significantly. As such, in our
 standardization effort it is not feasible to be prescriptive on the matter of
@@ -159,7 +159,7 @@ Similar to other OpenTelemetry signals, we target production environments. Thus,
 profiling signal must be implementable with low overhead and conforming to
 OpenTelemetry-wide runtime overhead / intrusiveness and wire data size requirements.
 
-## Promoting cloud-native best practices with profiling
+## Promoting cloud native best practices with profiling
 
 The CNCF’s mission states: _Cloud native technologies empower organizations to
 build and run scalable applications in modern, dynamic environments such as
diff --git a/oteps/profiles/0239-profiles-data-model.md b/oteps/profiles/0239-profiles-data-model.md
index a4a0458e81f..acce8ddc7e3 100644
--- a/oteps/profiles/0239-profiles-data-model.md
+++ b/oteps/profiles/0239-profiles-data-model.md
@@ -43,7 +43,7 @@ Introduces Data Model for Profiles signal to OpenTelemetry.
   * [Benchmarking](#benchmarking)
     * ["average" Profile](#average-profile)
     * ["average" Profile With Timestamps Added to Each Sample](#average-profile-with-timestamps-added-to-each-sample)
-    * ["ruby" Profile With Very Deep Stacktraces](#ruby-profile-with-very-deep-stacktraces)
+    * ["Ruby" Profile With Very Deep Stacktraces](#ruby-profile-with-very-deep-stacktraces)
     * ["large" Profile](#large-profile)
     * [Conclusions](#conclusions)
   * [Semantic Conventions](#semantic-conventions)
@@ -74,7 +74,7 @@ These goals are based on the vision set out in [Profiling Vision OTEP](./0212-pr
 * Standardize profiling data model for industry-wide sharing and reuse.
 * Profilers must be implementable with low overhead and conforming to OpenTelemetry-wide runtime overhead/intrusiveness and wire data size requirements.
 
-The last point is particularly important in the context of profiling. Profilers generate large amounts of data, and users of profiling technology are very sensitive to the overhead that profiling introduces. In the past high overhead has been a blocker for wider adoption of continuous profiling and was one of the reasons why profiling was not used in production environments. Therefore, it is important to make sure that the overhead of handling the profiling data on the client side as well as in intermediaries (e.g collector) is minimal.
+The last point is particularly important in the context of profiling. Profilers generate large amounts of data, and users of profiling technology are very sensitive to the overhead that profiling introduces. In the past high overhead has been a blocker for wider adoption of continuous profiling and was one of the reasons why profiling was not used in production environments. Therefore, it is important to make sure that the overhead of handling the profiling data on the client-side as well as in intermediaries (e.g collector) is minimal.
 
 ## Data Model
 
@@ -119,7 +119,7 @@ It is not forward compatible, meaning that a pprof file generated by the new pro
 
 Proto definition is based on [pprof format](https://github.com/google/pprof/blob/main/proto/profile.proto).
 
-In the landscape of performance profiling tools, pprof's data format stands as a clear industry standard. Its evolution and enduring relevance are a reflection of its effectiveness in addressing diverse and complex performance profiling needs. Major technology firms and open-source projects alike routinely employ pprof, underscoring its universal applicability and reliability.
+In the landscape of performance profiling tools, pprof's data format stands as a clear industry standard. Its evolution and enduring relevance are a reflection of its effectiveness in addressing diverse and complex performance profiling needs. Major technology firms and open source projects alike routinely employ pprof, underscoring its universal applicability and reliability.
 
 According to the [data from Profilerpedia](https://docs.google.com/spreadsheets/d/1UM-WFQhNf4GcyXmluSUGnMbOenvN-TqP2HQC9-Y50Lc/edit?usp=sharing), pprof is one of the most widely used formats. Compared to other formats it has the highest number of profilers, UIs, formats it can be converted to and from.
 
@@ -409,7 +409,7 @@ message Profile {
   // should not be used to store any machine-readable information, it is only
   // for human-friendly content. The profile must stay functional if this field
   // is cleaned.
-  repeated int64 comment = 13; // Indices into string table.
+  repeated int64 comment = 13; // Indexes into string table.
   // Index into the string table of the type of the preferred sample
   // value. If unset, clients should default to the last sample value.
   int64 default_sample_type = 14;
@@ -515,7 +515,7 @@ message ValueType {
 // augmented with auxiliary information like the thread-id, some
 // indicator of a higher level request being handled etc.
 message Sample {
-  // The indices recorded here correspond to locations in Profile.location.
+  // The indexes recorded here correspond to locations in Profile.location.
   // The leaf is at location_index[0]. [deprecated, superseded by locations_start_index / locations_length]
   repeated uint64 location_index = 1;
   // locations_start_index along with locations_length refers to to a slice of locations in Profile.location.
@@ -767,7 +767,7 @@ This field is semantically required and it is expected that end_time >= start_ti
 
 ##### Field `attributes`
 
-attributes is a collection of key/value pairs. Note, global attributes
+attributes is a collection of key-value pairs. Note, global attributes
 like server name can be set using the resource API.
 
 ##### Field `dropped_attributes_count`
@@ -824,8 +824,8 @@ mappings to binaries, locations, functions, string table, and additional metadat
 ##### Field `sample_type`
 
 A description of the samples associated with each Sample.value.
-For a cpu profile this might be:
-[["cpu","nanoseconds"]] or [["wall","seconds"]] or [["syscall","count"]]
+For a CPU profile this might be:
+[["CPU","nanoseconds"]] or [["wall","seconds"]] or [["syscall","count"]]
 For a heap profile, this might be:
 [["allocations","count"], ["space","bytes"]],
 If one of the values represents the number of events represented
@@ -873,13 +873,13 @@ string_table[0] must always be "".
 ##### Field `drop_frames`
 
 frames with Function.function_name fully matching the following
-regexp will be dropped from the samples, along with their successors.
+regular expression will be dropped from the samples, along with their successors.
 
 ##### Field `keep_frames`
 
 Index into string table.
 frames with Function.function_name fully matching the following
-regexp will be kept, even if it matches drop_frames.
+regular expression will be kept, even if it matches drop_frames.
 
 ##### Field `time_nanos`
 
@@ -895,7 +895,7 @@ Duration of the profile, if a duration makes sense.
 ##### Field `period_type`
 
 The kind of events between sampled occurrences.
-e.g [ "cpu","cycles" ] or [ "heap","bytes" ]
+e.g [ "CPU","cycles" ] or [ "heap","bytes" ]
 
 ##### Field `period`
 
@@ -911,7 +911,7 @@ is cleaned.
 
 ##### Field `default_sample_type`
 
-Indices into string table.
+Indexes into string table.
 Index into the string table of the type of the preferred sample
 value. If unset, clients should default to the last sample value.
 </details>
@@ -944,7 +944,7 @@ indicator of a higher level request being handled etc.
 
 ##### Field `location_index`
 
-The indices recorded here correspond to locations in Profile.location.
+The indexes recorded here correspond to locations in Profile.location.
 The leaf is at location_index[0]. [deprecated, superseded by locations_start_index / locations_length]
 
 ##### Field `locations_start_index`
@@ -959,7 +959,7 @@ Supersedes location_index.
 
 ##### Field `stacktrace_id_index`
 
-A 128bit id that uniquely identifies this stacktrace, globally. Index into string table. [optional]
+A 128bit ID that uniquely identifies this stacktrace, globally. Index into string table. [optional]
 
 ##### Field `value`
 
@@ -973,7 +973,7 @@ lists of the originals.
 ##### Field `label`
 
 label includes additional context for this sample. It can include
-things like a thread id, allocation size, etc.
+things like a thread ID, allocation size, etc.
 NOTE: While possible, having multiple values for the same label key is
 strongly discouraged and should never be used. Most tools (e.g. pprof) do
 not have good (or any) support for multi-value labels. And an even more
@@ -1038,8 +1038,8 @@ Describes function and line table debug information.
 
 ##### Field `id`
 
-Unique nonzero id for the location.  A profile could use
-instruction addresses or any integer sequence as ids. [deprecated]
+Unique nonzero ID for the location.  A profile could use
+instruction addresses or any integer sequence as IDs. [deprecated]
 
 ##### Field `mapping_index`
 
@@ -1074,7 +1074,7 @@ profile changes.
 
 ##### Field `type_index`
 
-Type of frame (e.g. kernel, native, python, hotspot, php). Index into string table.
+Type of frame (e.g. kernel, native, Python, hotspot, PHP). Index into string table.
 
 ##### Field `attributes`
 
@@ -1111,7 +1111,7 @@ file offset, and metadata like build ID
 
 ##### Field `id`
 
-Unique nonzero id for the mapping. [deprecated]
+Unique nonzero ID for the mapping. [deprecated]
 
 ##### Field `memory_start`
 
@@ -1141,7 +1141,7 @@ it could be the contents of the .note.gnu.build-id field.
 ##### Field `build_id_kind`
 
 Index into string table
-Specifies the kind of build id. See BuildIdKind enum for more details [optional]
+Specifies the kind of build ID. See BuildIdKind enum for more details [optional]
 
 ##### Field `attributes`
 
@@ -1162,7 +1162,7 @@ source file, and starting line number in the source.
 
 ##### Field `id`
 
-Unique nonzero id for the function. [deprecated]
+Unique nonzero ID for the function. [deprecated]
 
 ##### Field `name`
 
@@ -1407,7 +1407,7 @@ This section describes other existing popular formats and alternative representa
 
 ### Other Popular Formats
 
-Many other popular formats were considered as part of the process of designing this format. The popularity was assessed based on [data from Profilerpedia website](https://docs.google.com/spreadsheets/d/1UM-WFQhNf4GcyXmluSUGnMbOenvN-TqP2HQC9-Y50Lc/edit?usp=sharing). This chapter describes the most notable formats that were considered.
+Many other popular formats were considered as part of the process of designing this format. The popularity was assessed based on [data from Profilerpedia site](https://docs.google.com/spreadsheets/d/1UM-WFQhNf4GcyXmluSUGnMbOenvN-TqP2HQC9-Y50Lc/edit?usp=sharing). This chapter describes the most notable formats that were considered.
 
 #### Folded Stacks
 
@@ -1431,7 +1431,7 @@ In the process of refining the data model, multiple alternative representations
 
 * `pprof` representation is data in original pprof format.
 * `denormalized` representation, where all messages are embedded and no references by index are used. This is the simplest representation, but it is also the least efficient (by a huge margin) in terms of CPU utilization, memory consumption and size of the resulting protobuf payload.
-* `normalized` representation, where messages that repeat often are stored in separate tables and are referenced by indices. See [this chapter](#relationships-between-messages) for more details. This technique reduces the size of the resulting protobuf payload and the number of objects that need to be allocated to parse such payload.
+* `normalized` representation, where messages that repeat often are stored in separate tables and are referenced by indexes. See [this chapter](#relationships-between-messages) for more details. This technique reduces the size of the resulting protobuf payload and the number of objects that need to be allocated to parse such payload.
 * `arrays` representation, which is based on `normalized` representation, but uses arrays of integers instead of arrays of structures to represent messages. It further reduces the number of allocations, and the size of the resulting protobuf payload.
 * `pprofextended` is a modified `pprof` representation. It is the one presented in this OTEP.
 
@@ -1494,7 +1494,7 @@ The source is the same as in the previous example, but this time there were time
 |arrays|8,877|3,309|588|1|946,468|3,306|
 |pprofextended|8,863|3,387|806|1|919,904|1,476|
 
-#### "ruby" Profile With Very Deep Stacktraces
+#### "Ruby" Profile With Very Deep Stacktraces
 
 The source for this test is an aggregated pprof profile collected from a Ruby application that has very deep stacktraces.
 
@@ -1530,7 +1530,7 @@ After running many benchmarks and analyzing the results, we came to the followin
 
 ### Semantic Conventions
 
-We plan to leverage OTEL Semantic Conventions for various attributes and enums such as profile types or units. Here's a non-exhaustive list of semantic conventions that are used in data model. It is expected to be polished and extended in the future.
+We plan to leverage OTel Semantic Conventions for various attributes and enums such as profile types or units. Here's a non-exhaustive list of semantic conventions that are used in data model. It is expected to be polished and extended in the future.
 
 #### Profile Types
 
@@ -1591,7 +1591,7 @@ We intend to research this question in the future while we experiment with early
 
 ## Future Possibilities
 
-This OTEP enables us to start working on various parts of [OTEL Specification](https://github.com/open-telemetry/opentelemetry-specification):
+This OTEP enables us to start working on various parts of [OTel Specification](https://github.com/open-telemetry/opentelemetry-specification):
 
 * Profiles Data Model
 * Profiles API
@@ -1599,5 +1599,5 @@ This OTEP enables us to start working on various parts of [OTEL Specification](h
 
 That in turn would enable us to start working on:
 
-* Profiles support in [OTEL Collector](https://github.com/open-telemetry/opentelemetry-collector)
+* Profiles support in [OTel Collector](https://github.com/open-telemetry/opentelemetry-collector)
 * Client SDK implementations in various languages (e.g Go and Java)
diff --git a/oteps/trace/0006-sampling.md b/oteps/trace/0006-sampling.md
index b1bb9ca020a..6e695017b87 100644
--- a/oteps/trace/0006-sampling.md
+++ b/oteps/trace/0006-sampling.md
@@ -77,12 +77,12 @@ backwards incompatible compared to adding a new API.
 
 Examples: HBase, Envoy developers.
 
-* They are shipping self-contained binaries that may accept YAML or similar run-time configuration,
+* They are shipping self-contained binaries that may accept YAML or similar runtime configuration,
  but are not expected to support extensibility/plugins beyond the default OpenTelemetry SDK,
  OpenTelemetry SDKTracer, and OpenTelemetry wire format exporter.
 * They may have their own recommendations for sampling rates, but don't run the binaries in
  production, only provide packaged binaries. So their sampling rate configs, and sampling strategies
- need to be a finite "built in" set from OpenTelemetry's SDK.
+ need to be a finite "built-in" set from OpenTelemetry's SDK.
 * They need to deal with upstream sampling decisions made by services that call them.
 
 **Solution:**
@@ -169,7 +169,7 @@ OpenTelemetry API has two flags/properties:
   * Users can use this property to determine if expensive trace events can be avoided.
 * `SampledFlag`
   * This flag is propagated via the `TraceOptions` to the child Spans (e.g.
-   `TraceOptions.isSampled()`). For more details see the w3c definition [here][trace-flags].
+   `TraceOptions.isSampled()`). For more details see the W3C definition [here][trace-flags].
   * In Dapper based systems this is equivalent to `Span` being `sampled` and exported.
 
 The flag combination `SampledFlag == false` and `RecordEvents == true` means that the current `Span`
@@ -299,7 +299,7 @@ The SDK must call the `Sampler` every time a `Span` is created during the start
      when the logical `Span` operation should start.
   * Cons:
     * The most common case would have required an extra API call.
-    * Error prone, users may forget to call the extra API.
+    * Error-prone, users may forget to call the extra API.
     * Unexpected and hard to find errors if user tries to create a child `Span` before calling
      MakeSamplingDecision().
 * We considered allowing the sampling decision to be arbitrarily delayed, but guaranteed before
diff --git a/oteps/trace/0059-otlp-trace-data-format.md b/oteps/trace/0059-otlp-trace-data-format.md
index eb72afb8630..f838ac03c27 100644
--- a/oteps/trace/0059-otlp-trace-data-format.md
+++ b/oteps/trace/0059-otlp-trace-data-format.md
@@ -14,7 +14,7 @@ OTLP Trace Data Format is primarily inherited from OpenCensus protocol. Several
 
 1. Removed `Node` as a concept.
 2. Extended `Resource` to better describe the source of the telemetry data.
-3. Replaced attribute maps by lists of key/value pairs.
+3. Replaced attribute maps by lists of key-value pairs.
 4. Eliminated unnecessary additional nesting in various values.
 
 Changes 1-2 are conceptual, changes 3-4 improve performance.
@@ -317,7 +317,7 @@ message AttributeKeyValue {
 
 ## Trade-offs and mitigations
 
-Timestamps were changed from google.protobuf.Timestamp to a int64 representation in Unix epoch nanoseconds. This change reduces the type-safety but benchmarks show that for small spans there is 15-20% encoding/decoding CPU speed gain. This is the right trade-off to make because encoding/decoding CPU consumption tends to dominate many workloads (particularly in OpenTelemetry Service).
+Timestamps were changed from google.protobuf.Timestamp to a int64 representation in UNIX epoch nanoseconds. This change reduces the type-safety but benchmarks show that for small spans there is 15-20% encoding/decoding CPU speed gain. This is the right trade-off to make because encoding/decoding CPU consumption tends to dominate many workloads (particularly in OpenTelemetry Service).
 
 ## Prior art and alternatives
 
@@ -368,4 +368,4 @@ The benchmark encodes/decodes 1000 batches of 100 spans, each span containing 3
 
 The results show OTLP/AttrList is 5-6 times faster than OpenCensus in encoding and about 3 times faster in decoding.
 
-Using google.protobuf.Timestamp instead of int64-encoded unix timestamp results in 1.18-1.32 times slower encoding and 1.21-1.38 times slower decoding (depending on what the span contains).
+Using google.protobuf.Timestamp instead of int64-encoded UNIX timestamp results in 1.18-1.32 times slower encoding and 1.21-1.38 times slower decoding (depending on what the span contains).
diff --git a/oteps/trace/0136-error_flagging.md b/oteps/trace/0136-error_flagging.md
index 8929820e883..8ec5ae46c72 100644
--- a/oteps/trace/0136-error_flagging.md
+++ b/oteps/trace/0136-error_flagging.md
@@ -16,7 +16,7 @@ While generic instrumentation can only provide a generic schema, end users are c
 
 ## Explanation
 
-The following changes add several missing features required for proper error reporting, and are completely backwards compatible with OpenTelemetry today.
+The following changes add several missing features required for proper error reporting, and are completely backward compatible with OpenTelemetry today.
 
 ### Status Codes
 
@@ -56,7 +56,7 @@ Note that these convenience methods simply wire together multiple API calls. The
 
 ## Internal details
 
-This proposal is mostly backwards compatible with existing code, protocols, and the OpenTracing bridge. The only potential exception is the removal of status code enums from the current OTLP protocol, and the rewriting of the small number of instrumentation that were making use of them.
+This proposal is mostly backward compatible with existing code, protocols, and the OpenTracing bridge. The only potential exception is the removal of status code enums from the current OTLP protocol, and the rewriting of the small number of instrumentation that were making use of them.
 
 ## BUT ERRORS ARE SUBJECTIVE!! HOW CAN WE KNOW WHAT IS AN ERROR? WHO ARE WE TO DEFINE THIS?
 
diff --git a/oteps/trace/0170-sampling-probability.md b/oteps/trace/0170-sampling-probability.md
index d7b66556302..8b8c3369c05 100644
--- a/oteps/trace/0170-sampling-probability.md
+++ b/oteps/trace/0170-sampling-probability.md
@@ -515,7 +515,7 @@ reproduced here.
 
 This kind of Sampler allows non-root spans in a trace to raise the
 probability of tracing, using a conditional probability formula shown
-below.  Traces produced in this way are complete sub-trees, not
+below.  Traces produced in this way are complete subtrees, not
 necessarily complete.  This technique is successful especially in
 systems where a high-throughput service on occasion calls a
 low-throughput service.  Low-throughput services are meant to inflate
diff --git a/oteps/trace/0174-http-semantic-conventions.md b/oteps/trace/0174-http-semantic-conventions.md
index 73bbd433ef5..0166cbc9b64 100644
--- a/oteps/trace/0174-http-semantic-conventions.md
+++ b/oteps/trace/0174-http-semantic-conventions.md
@@ -110,7 +110,7 @@ Related issue: [open-telemetry/opentelemetry-specification#2114](https://github.
 ### Security concerns
 
 Some attributes can contain potentially sensitive information. Most likely, by
-default web frameworks/http clients should not expose that. For example,
+default web frameworks/HTTP clients should not expose that. For example,
 `http.target` has a query string that may contain credentials.
 
 > [!NOTE]
@@ -148,7 +148,7 @@ There is a lot of user feedback that they want it, but
 * We can let users collect them
 * Attaching to server span is trivial
 * Spec for client: we should have an approach to let users unambiguously
-  associate body with http client span (e.g. outer manual span that wraps HTTP
+  associate body with HTTP client span (e.g. outer manual span that wraps HTTP
   call and response reading and has event/log with body)
 * Reading/writing body may happen outside of HTTP client API (e.g. through
   network streams) – how users can track it too?
@@ -168,7 +168,7 @@ limited to, are considered out of scope for this workgroup:
 * Fan-in and fan-out operations (e.g., GraphQL).
 * Hedging policies. Hedging enables aggressively sending multiple copies of a
   single request without waiting for a response. Hedged RPCs may be be executed
-  multiple times on the server side, typically by different backends.
+  multiple times on the server-side, typically by different backends.
 * HTTP as a transport layer for other systems (e.g., Messaging system built on
   top of HTTP).
 
diff --git a/oteps/trace/0220-messaging-semantic-conventions-span-structure.md b/oteps/trace/0220-messaging-semantic-conventions-span-structure.md
index a05b18b911c..533e6fa3039 100644
--- a/oteps/trace/0220-messaging-semantic-conventions-span-structure.md
+++ b/oteps/trace/0220-messaging-semantic-conventions-span-structure.md
@@ -186,9 +186,9 @@ to receiving the message from intermediaries, but instead refer to the
 application receiving messages for processing. If messages are fetched from the
 intermediary and forwarded to the application in one go, the whole operation
 might be covered by a "Deliver" or "Receive" span. However, libraries or SDKs
-might pre-fetch messages from intermediaries and cache those messages, and only
+might prefetch messages from intermediaries and cache those messages, and only
 forward messages to the application at a later time. In this case, the
-operation of pre-fetching and caching should not be covered by the "Deliver" or
+operation of prefetching and caching should not be covered by the "Deliver" or
 "Receive" spans.
 
 Operations covered by "Deliver" or "Receive" can forward zero messages (e. g.
@@ -305,7 +305,7 @@ application when those operations are initiated by the application code.
 ##### General considerations
 
 "Deliver" or "Receive" spans MUST NOT be created for messages which are not
-forwarded to the caller, but are pre-fetched or cached by messaging
+forwarded to the caller, but are prefetched or cached by messaging
 libraries or SDKs.
 
 A single "Deliver" or "Receive" span can account for a single message, for
diff --git a/oteps/trace/0235-sampling-threshold-in-trace-state.md b/oteps/trace/0235-sampling-threshold-in-trace-state.md
index cec19441f6f..d0ec2a84054 100644
--- a/oteps/trace/0235-sampling-threshold-in-trace-state.md
+++ b/oteps/trace/0235-sampling-threshold-in-trace-state.md
@@ -40,7 +40,7 @@ C (being a parent based sampler) samples a span purely based on its parent (B in
 
 This design requires that as a given span progresses along its collection path, `th` is non-decreasing (and, in particular, must be increased at stages that apply lower sampling probabilities).
 It does not, however, restrict a span's initial `th` in any way (e.g., relating it to that of its parent, if it has one).
-It is acceptable for B to have a lesser initial `th` than A has. It would not be ok if some later-stage sampler decreased A's `th`.
+It is acceptable for B to have a lesser initial `th` than A has. It would not be OK if some later-stage sampler decreased A's `th`.
 
 The system has the following invariant:
 
diff --git a/oteps/trace/0250-Composite_Samplers.md b/oteps/trace/0250-Composite_Samplers.md
index 02b85ca9694..7b82a66ce69 100644
--- a/oteps/trace/0250-Composite_Samplers.md
+++ b/oteps/trace/0250-Composite_Samplers.md
@@ -1,6 +1,6 @@
 # Composite Samplers Proposal
 
-This proposal addresses head-based sampling as described by the [Open Telemetry SDK](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#sampling).
+This proposal addresses head-based sampling as described by the [OpenTelemetry SDK](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#sampling).
 It introduces additional _composite samplers_.
 Composite samplers use other samplers (_delegates_ or _children_) to make sampling decisions.
 The composite samplers invoke the delegate samplers, but eventually make the final call.
@@ -52,7 +52,7 @@ Unfortunately, some of the valuable ideas flowing at the sampling SIG meetings n
 
 ## The Goal
 
-The goal of this proposal is to help creating advanced sampling configurations using pre-defined building blocks. Let's consider the following example of sampling requirements. It is believed that many users will have requirements following a similar pattern. Most notable elements here are trace classification based on target URL, some spans requiring special handling, and putting a sanity cap on the total volume of exported spans.
+The goal of this proposal is to help creating advanced sampling configurations using predefined building blocks. Let's consider the following example of sampling requirements. It is believed that many users will have requirements following a similar pattern. Most notable elements here are trace classification based on target URL, some spans requiring special handling, and putting a sanity cap on the total volume of exported spans.
 
 Since this is a new part of the sampler specification, it is expected to be an optional component for OpenTelemetry SDKs. However, if an SDK _opts-in_, it SHOULD implement all samplers described herein.
 
@@ -325,7 +325,7 @@ A number of composite samplers are already available as independent contribution
 ([RuleBasedRoutingSampler](https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/samplers/src/main/java/io/opentelemetry/contrib/sampler/RuleBasedRoutingSampler.java),
 [Stratified Sampling](https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/trace/stratified-sampling-example),
 LinksBasedSampler [for Java](https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/samplers/src/main/java/io/opentelemetry/contrib/sampler/LinksBasedSampler.java)
-and [for DOTNET](https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/trace/links-based-sampler)).
+and [for .NET](https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/trace/links-based-sampler)).
 Also, historically, some Span categorization was introduced by [JaegerRemoteSampler](https://www.jaegertracing.io/docs/2.14/architecture/sampling/#remote-sampling).
 
 This proposal aims at generalizing these ideas, and at providing a bit more formal specification for the behavior of the composite samplers.
diff --git a/package.json b/package.json
index dfc038bbc1d..a4a77ba7210 100644
--- a/package.json
+++ b/package.json
@@ -4,6 +4,12 @@
     "cspell": "9.7.0",
     "markdown-link-check": "3.14.2",
     "markdown-toc": "1.2.0",
-    "markdownlint-cli": "0.48.0"
+    "markdownlint-cli": "0.48.0",
+    "textlint": "15.5.1",
+    "textlint-filter-rule-allowlist": "4.0.0",
+    "textlint-filter-rule-comments": "1.3.0",
+    "textlint-rule-common-misspellings": "1.0.1",
+    "textlint-rule-period-in-header": "0.1.2",
+    "textlint-rule-terminology": "5.2.16"
   }
 }
diff --git a/specification/common/README.md b/specification/common/README.md
index eef36656258..282ec85faf5 100644
--- a/specification/common/README.md
+++ b/specification/common/README.md
@@ -68,7 +68,7 @@ However, if it is impossible to make sure that no `null` values are accepted
 processors / exporters as `null`). If exporters do not support exporting `null`
 values, they MAY replace those values by 0, `false`, or empty strings.
 This is required for map/dictionary structures represented as two arrays with
-indices that are kept in sync (e.g., two attributes `header_keys` and `header_values`,
+indexes that are kept in sync (e.g., two attributes `header_keys` and `header_values`,
 both containing an array of strings to represent a mapping
 `header_keys[i] -> header_values[i]`).
 
diff --git a/specification/compatibility/logging_trace_context.md b/specification/compatibility/logging_trace_context.md
index 884d35246cc..17721136c98 100644
--- a/specification/compatibility/logging_trace_context.md
+++ b/specification/compatibility/logging_trace_context.md
@@ -34,7 +34,7 @@ which combination of fields is considered valid).
 
 ### Syslog RFC5424
 
-Trace id, span id and traceflags SHOULD be recorded via SD-ID "opentelemetry".
+Trace ID, span ID and traceflags SHOULD be recorded via SD-ID "OpenTelemetry".
 
 For example:
 
diff --git a/specification/compatibility/prometheus_and_openmetrics.md b/specification/compatibility/prometheus_and_openmetrics.md
index d53101cdb2c..f4b91ecd339 100644
--- a/specification/compatibility/prometheus_and_openmetrics.md
+++ b/specification/compatibility/prometheus_and_openmetrics.md
@@ -285,7 +285,7 @@ OpenTelemetry histograms. Exemplars on counter metric points SHOULD be
 converted to exemplars on OpenTelemetry sums. If present, the timestamp
 MUST be added to the OpenTelemetry exemplar. The Trace ID and Span ID SHOULD be
 retrieved from the `trace_id` and `span_id` label keys, respectively.  All
-labels not used for the trace and span ids MUST be added to the OpenTelemetry
+labels not used for the trace and span IDs MUST be added to the OpenTelemetry
 exemplar as attributes.
 
 ### Instrumentation Scope
@@ -381,7 +381,7 @@ metric points, the exporter SHOULD warn the user through error logging.
 
 The Name of an OTLP metric MUST be added as the
 [Prometheus Metric Name](https://prometheus.io/docs/instrumenting/exposition_formats/#comments-help-text-and-type-information).
-Prometheus naming conventions encourage metric names to match the regex: `[a-zA-Z_:]([a-zA-Z0-9_:])*`. Discouraged characters
+Prometheus naming conventions encourage metric names to match the regular expression: `[a-zA-Z_:]([a-zA-Z0-9_:])*`. Discouraged characters
 in the metric name SHOULD be replaced with the `_` character by default, aiming for compatibility with Prometheus conventions. Multiple
 consecutive `_` characters SHOULD be replaced with a single `_` character.
 
@@ -527,7 +527,7 @@ OpenTelemetry Metric Attributes MUST be converted to
 String Attribute values are converted directly to Metric Attributes, and
 non-string Attribute values MUST be converted to string attributes following
 the [attribute specification](../common/README.md#attribute).  Prometheus
-naming conventions encourage metric names to match the following regex:
+naming conventions encourage metric names to match the following regular expression:
 `[a-zA-Z_]([a-zA-Z0-9_])*`. Discouraged characters SHOULD be replace with the `_` character.
 Multiple consecutive `_` characters SHOULD be replaced with a single `_`
 character. This may cause ambiguity in scenarios where multiple similar-named
diff --git a/specification/configuration/sdk-environment-variables.md b/specification/configuration/sdk-environment-variables.md
index c5a199a57c5..c3da58e16e1 100644
--- a/specification/configuration/sdk-environment-variables.md
+++ b/specification/configuration/sdk-environment-variables.md
@@ -221,7 +221,7 @@ usage in Zipkin Exporter configuration:
 
 - `OTEL_EXPORTER_ZIPKIN_PROTOCOL`
 
-This will be used to specify whether or not the exporter uses v1 or v2, json,
+This will be used to specify whether or not the exporter uses v1 or v2, JSON,
 thrift or protobuf.  As of 1.0 of the specification, there
 _is no specified default, or configuration via environment variables_.
 
diff --git a/specification/configuration/sdk.md b/specification/configuration/sdk.md
index 40d0fe5d0c8..416737e4fdb 100644
--- a/specification/configuration/sdk.md
+++ b/specification/configuration/sdk.md
@@ -140,7 +140,7 @@ The following table lists the current status of all SDK plugin components in the
 | [span exporter](../trace/sdk.md#span-exporter)                                              | [SpanExporter](https://github.com/open-telemetry/opentelemetry-configuration/blob/main/schema-docs.md#spanexporter-)                                   |
 | [span processor](../trace/sdk.md#span-processor)                                            | [SpanProcessor](https://github.com/open-telemetry/opentelemetry-configuration/blob/main/schema-docs.md#spanprocessor-)                                 |
 | [sampler](../trace/sdk.md#sampler)                                                          | [Sampler](https://github.com/open-telemetry/opentelemetry-configuration/blob/main/schema-docs.md#sampler-)                                             |
-| [id generator](../trace/sdk.md#id-generators)                                               | not yet available [#70](https://github.com/open-telemetry/opentelemetry-configuration/issues/70)                                                       |
+| [ID generator](../trace/sdk.md#id-generators)                                               | not yet available [#70](https://github.com/open-telemetry/opentelemetry-configuration/issues/70)                                                       |
 | [pull metric reader](../metrics/sdk.md#metricreader)                                        | [PullMetricExporter](https://github.com/open-telemetry/opentelemetry-configuration/blob/main/schema-docs.md#pullmetricexporter-)                       |
 | [push metric exporter](../metrics/sdk.md#metricexporter)                                    | [PushMetricExporter](https://github.com/open-telemetry/opentelemetry-configuration/blob/main/schema-docs.md#pushmetricexporter-)                       |
 | [metric producer](../metrics/sdk.md#metricproducer)                                         | [MetricProducer](https://github.com/open-telemetry/opentelemetry-configuration/blob/main/schema-docs.md#metricproducer-)                               |
@@ -195,7 +195,7 @@ Parse and validate a [configuration file](./data-model.md#file-based-configurati
 
 * `file`: The [configuration file](./data-model.md#file-based-configuration-model) to parse. This MAY be a
   file path, or language specific file data structure, or a stream of a file's content.
-* `file_format`: The file format of the `file` (e.g. [yaml](./data-model.md#yaml-file-format)).
+* `file_format`: The file format of the `file` (e.g. [YAML](./data-model.md#yaml-file-format)).
   Implementations MAY accept a `file_format` parameter, or infer it from
   the `file` extension, or include file format specific overloads of `parse`,
   e.g. `parseYaml(file)`. If `parse` accepts `file_format`, the API SHOULD be
@@ -225,7 +225,7 @@ user MUST not be required to specify an empty object (i.e. `drop: {}`) in these
 cases.
 
 When encountering a reference to
-a [SDK extension component](#sdk-extension-components) which is not built in to
+a [SDK extension component](#sdk-extension-components) which is not built-in to
 the SDK, Parse MUST resolve corresponding configuration to a
 generic [ConfigProperties](./api.md#configproperties) representation as described
 in [Create Component](#create-component).
@@ -284,7 +284,7 @@ and `ca_file` is not an absolute file path as defined in the property
 description, return an error.
 
 When encountering a reference to
-an [SDK plugin component](#sdk-extension-components) which is not built in to
+an [SDK plugin component](#sdk-extension-components) which is not built-in to
 the SDK, Create MUST resolve the component using [Create Component](#create-component)
 of the [`PluginComponentProvider`](#plugincomponentprovider) of the corresponding `type`
 and `name` used to [register](#register-plugincomponentprovider), including the
@@ -300,7 +300,7 @@ initialization [error handling principles](../error-handling.md#basic-error-hand
 **Status**: [Development](../document-status.md) SDK implementations MAY provide
 options to allow programmatic customization of the components initialized by `Create`.
 This allows configuration of concepts which are not yet or may never be representable
-in the configuration model. For example, java OTLP exporters allow configuration
+in the configuration model. For example, Java OTLP exporters allow configuration
 of the [ExecutorService](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html),
 a niche but important option for applications which need strict control of thread pools.
 This programmatic customization might take the form of passing an optional callback to
@@ -327,7 +327,7 @@ component from the resolved top level SDK components.
 
 The SDK MUST provide a mechanism to
 register [`PluginComponentProvider`](#plugincomponentprovider). The mechanism MAY be
-language-specific and automatic. For example, a java implementation might use
+language-specific and automatic. For example, a Java implementation might use
 the [service provider interface](https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html)
 mechanism to register implementations of a particular interface
 as `PluginComponentProvider`s.
diff --git a/specification/context/api-propagators.md b/specification/context/api-propagators.md
index 2d0ef341469..a80b5452970 100644
--- a/specification/context/api-propagators.md
+++ b/specification/context/api-propagators.md
@@ -68,7 +68,7 @@ and is bound to a data type, in order to propagate in-band context data across p
 The Propagators API currently defines one `Propagator` type:
 
 - `TextMapPropagator` is a type that injects values into and extracts values
-  from carriers as string key/value pairs.
+  from carriers as string key-value pairs.
 
 ### Carrier
 
@@ -119,7 +119,7 @@ value as string key/values pairs into carriers that travel in-band across proces
 The carrier of propagated data on both the client (injector) and server (extractor) side is
 usually an HTTP request.
 
-In order to increase compatibility, the key/value pairs MUST only consist of US-ASCII characters
+In order to increase compatibility, the key-value pairs MUST only consist of US-ASCII characters
 that make up valid HTTP header fields as per [RFC 9110](https://datatracker.ietf.org/doc/html/rfc9110/#name-fields).
 
 `Getter` and `Setter` are optional helper components used for extraction and injection respectively,
@@ -159,7 +159,7 @@ the base [Inject](#inject) operation.
 
 Optional arguments:
 
-- A `Setter` to set a propagation key/value pair. Propagators MAY invoke it multiple times in order to set multiple pairs.
+- A `Setter` to set a propagation key-value pair. Propagators MAY invoke it multiple times in order to set multiple pairs.
   This is an additional argument that languages are free to define to help inject data into the carrier.
 
 #### Setter argument
@@ -303,7 +303,7 @@ Required arguments:
 
 If the `TextMapPropagator`'s `Inject` implementation accepts the optional `Setter` argument, the following arguments are REQUIRED, otherwise they are OPTIONAL:
 
-- The `Setter` to set a propagation key/value pair. Propagators MAY invoke it multiple times in order to set multiple pairs.
+- The `Setter` to set a propagation key-value pair. Propagators MAY invoke it multiple times in order to set multiple pairs.
 
 ## Global Propagators
 
@@ -393,7 +393,7 @@ When injecting and extracting trace context to or from a carrier, the following
 
 B3 has both single and multi-header encodings. It also has semantics that do not
 map directly to OpenTelemetry such as a debug trace flag, and allowing spans
-from both sides of request to share the same id. To maximize compatibility
+from both sides of request to share the same ID. To maximize compatibility
 between OpenTelemetry and Zipkin implementations, the following guidelines have
 been established for B3 context propagation.
 
@@ -407,7 +407,7 @@ When extracting B3, propagators:
 * MUST preserve a debug trace flag, if received, and propagate
   it with subsequent requests. Additionally, an OpenTelemetry implementation
   MUST set the sampled trace flag when the debug flag is set.
-* MUST NOT reuse `X-B3-SpanId` as the id for the server-side span.
+* MUST NOT reuse `X-B3-SpanId` as the ID for the server-side span.
 
 #### B3 Inject
 
@@ -417,7 +417,7 @@ When injecting B3, propagators:
 * MUST provide configuration to change the default injection format to B3
   multi-header
 * MUST NOT propagate `X-B3-ParentSpanId` as OpenTelemetry does not support
-  reusing the same id for both sides of a request.
+  reusing the same ID for both sides of a request.
 
 #### Fields
 
diff --git a/specification/entities/data-model.md b/specification/entities/data-model.md
index 06630da065c..da23026517e 100644
--- a/specification/entities/data-model.md
+++ b/specification/entities/data-model.md
@@ -49,16 +49,16 @@ physical format and encoding of how entity data is recorded).
 | Field | Type | Description |
 | ----- | ---- | ----------- |
 | Type | string | Defines the type of the entity. MUST not change during the lifetime of the entity. For example: "service" or "host". This field is required and MUST not be empty for valid entities. |
-| Id | map<string, attribute value> | Attributes that identify the entity.<p>MUST not change during the lifetime of the entity. The Id must contain at least one attribute.<p>Follows OpenTelemetry [attribute definition](../common/README.md#attribute). SHOULD follow OpenTelemetry [semantic conventions](https://github.com/open-telemetry/semantic-conventions) for attributes. |
+| ID | map<string, attribute value> | Attributes that identify the entity.<p>MUST not change during the lifetime of the entity. The ID must contain at least one attribute.<p>Follows OpenTelemetry [attribute definition](../common/README.md#attribute). SHOULD follow OpenTelemetry [semantic conventions](https://github.com/open-telemetry/semantic-conventions) for attributes. |
 | Description | map<string, attribute value> | Descriptive (non-identifying) attributes of the entity.<p>MAY change over the lifetime of the entity. MAY be empty. These attributes are not part of entity's identity.<p>Follows OpenTelemetry [attribute definition](../common/README.md#attribute). SHOULD follow OpenTelemetry [semantic conventions](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/README.md) for attributes. |
 
 ## Minimally Sufficient Identity
 
 Commonly, a number of attributes of an entity are readily available for the telemetry
-producer to compose an Id from. Of the available attributes the entity Id should
+producer to compose an ID from. Of the available attributes the entity ID should
 include the minimal set of attributes that is sufficient for uniquely identifying
 that entity. For example a Process on a host can be uniquely identified by
-(`process.pid`,`process.start_time`) attributes. Adding for example `process.executable.name` attribute to the Id is unnecessary and violates the
+(`process.pid`,`process.start_time`) attributes. Adding for example `process.executable.name` attribute to the ID is unnecessary and violates the
 Minimally Sufficient Identity rule.
 
 ## Repeatable Identity
diff --git a/specification/entities/entity-propagation.md b/specification/entities/entity-propagation.md
index e3863169f60..a46dda2a44f 100644
--- a/specification/entities/entity-propagation.md
+++ b/specification/entities/entity-propagation.md
@@ -38,7 +38,7 @@ can discover on its own.
 Common scenarios where entity propagation is beneficial include:
 
 - Container orchestration systems where the orchestrator knows container metadata
-- CI/CD pipelines where the build system knows job and environment details  
+- CI/CD pipelines where the build tool knows job and environment details  
 - Batch processing systems where the scheduler knows task context
 - Command-line tools spawned with specific entity context
 
diff --git a/specification/error-handling.md b/specification/error-handling.md
index f4eae3dfd04..7fd543043e9 100644
--- a/specification/error-handling.md
+++ b/specification/error-handling.md
@@ -10,12 +10,12 @@ This makes for some unique requirements with respect to error handling.
 
 ## Basic error handling principles
 
-OpenTelemetry implementations MUST NOT throw unhandled exceptions at run time.
+OpenTelemetry implementations MUST NOT throw unhandled exceptions at runtime.
 
 1. API methods MUST NOT throw unhandled exceptions when used incorrectly by end users.
    The API and SDK SHOULD provide safe defaults for missing or invalid arguments.
    For instance, a name like `empty` may be used if the user passes in `null` as the span name argument during `Span` construction.
-2. The API or SDK MAY _fail fast_ and cause the application to fail on initialization, e.g. because of a bad user config or environment, but MUST NOT cause the application to fail later at run time, e.g. due to dynamic config settings received from the Collector.
+2. The API or SDK MAY _fail fast_ and cause the application to fail on initialization, e.g. because of a bad user config or environment, but MUST NOT cause the application to fail later at runtime, e.g. due to dynamic config settings received from the Collector.
 3. The SDK MUST NOT throw unhandled exceptions for errors in their own operations.
    For example, an exporter should not throw an exception when it cannot reach the endpoint to which it sends telemetry data.
 
@@ -37,10 +37,10 @@ OpenTelemetry implementations MUST NOT throw unhandled exceptions at run time.
 ## Error handling and performance
 
 Error handling and extensive input validation may cause performance degradation, especially on dynamic languages where the input object types are not guaranteed in compile time.
-Runtime type checks will impact performance and are error prone, exceptions may occur despite the best effort.
+Runtime type checks will impact performance and are error-prone, exceptions may occur despite the best effort.
 
 It is recommended to have a global exception handling logic that will guarantee that exceptions are not leaking to the user code.
-And make a reasonable trade off of the SDK performance and fullness of type checks that will provide a better on-error behavior and SDK errors troubleshooting.
+And make a reasonable trade-off of the SDK performance and fullness of type checks that will provide a better on-error behavior and SDK errors troubleshooting.
 
 ## Self-diagnostics
 
diff --git a/specification/glossary.md b/specification/glossary.md
index 3dfdabfdf4f..64405a7a486 100644
--- a/specification/glossary.md
+++ b/specification/glossary.md
@@ -105,11 +105,11 @@ Metrics, logs, and traces exported to telemetry backends are examples of out-of-
 
 ### Manual Instrumentation
 
-Coding against the OpenTelemetry API such as the [Tracing API](trace/api.md), [Metrics API](metrics/api.md), or others to collect telemetry from end-user code or shared frameworks (e.g. MongoDB, Redis, etc.).
+Coding against the OpenTelemetry API such as the [Tracing API](trace/api.md), [Metrics API](metrics/api.md), or others to collect telemetry from end user code or shared frameworks (e.g. MongoDB, Redis, etc.).
 
 ### Automatic Instrumentation
 
-Refers to telemetry collection methods that do not require the end-user to modify application's source code.
+Refers to telemetry collection methods that do not require the end user to modify application's source code.
 Methods vary by programming language, and examples include code manipulation (during compilation or at runtime),
 monkey patching, or running eBPF programs.
 
@@ -207,7 +207,7 @@ object, in the [Events](trace/api.md#add-events) list.
 
 ### Log Attributes
 
-Key/value pairs contained in a `Log Record`.
+Key-value pairs contained in a `Log Record`.
 
 ### Structured Logs
 
diff --git a/specification/library-guidelines.md b/specification/library-guidelines.md
index ffa8beaf352..5b9c445bfd6 100644
--- a/specification/library-guidelines.md
+++ b/specification/library-guidelines.md
@@ -53,7 +53,7 @@ In order to enable telemetry the application must take a dependency on the OpenT
 
 ### API and Minimal Implementation
 
-The API package is a self-sufficient dependency, in the sense that if the end-user application or a third-party library depends only on it and does not plug a full SDK implementation then the application will still build and run without failing, although no telemetry data will be actually delivered to a telemetry backend.
+The API package is a self-sufficient dependency, in the sense that if the end user application or a third-party library depends only on it and does not plug a full SDK implementation then the application will still build and run without failing, although no telemetry data will be actually delivered to a telemetry backend.
 
 This self-sufficiency is achieved the following way.
 
@@ -87,13 +87,13 @@ Vendors are encouraged to keep protocol-specific exporters as simple as possible
 
 End users should be given the flexibility of making many of the decisions regarding the queuing, retrying, tagging, batching functionality that make the most sense for their application. For example, if an application's telemetry data must be delivered to a remote backend that has no guaranteed availability the end user may choose to use a persistent local queue and an `Exporter` to retry sending on failures. As opposed to that for an application that sends telemetry to a locally running Agent daemon, the end user may prefer to have a simpler exporting configuration without retrying or queueing.
 
-If additional exporters for the sdk are provided as separate libraries, the
+If additional exporters for the SDK are provided as separate libraries, the
 name of the library should be prefixed with the terms "OpenTelemetry" and "Exporter" in accordance with the naming conventions of the respective technology.
 
 For example:
 
 - Python and Java: opentelemetry-exporter-{vendor_name}
-- Javascript: @opentelemetry/exporter-{vendor_name}
+- JavaScript: @opentelemetry/exporter-{vendor_name}
 
 #### Resource Detection
 
@@ -101,7 +101,7 @@ Cloud vendors are encouraged to provide packages to detect resource information
 
 ### Alternative Implementations
 
-The end-user application may decide to take a dependency on alternative implementation.
+The end user application may decide to take a dependency on alternative implementation.
 
 SDK provides flexibility and extensibility that may be used by many implementations. Before developing an alternative implementation, please, review extensibility points provided by OpenTelemetry.
 
diff --git a/specification/library-layout.md b/specification/library-layout.md
index e3be935b7e7..b9c3d26f3d8 100644
--- a/specification/library-layout.md
+++ b/specification/library-layout.md
@@ -23,7 +23,7 @@ api
    └── logs
 ```
 
-> Use of lowercase, CamelCase or Snake Case (stylized as snake_case) names depends on the language.
+> Use of lowercase, camelCase or snake_case names depends on the language.
 
 ### `/api/context`
 
@@ -74,7 +74,7 @@ sdk
    └── logs
 ```
 
-> Use of lowercase, CamelCase or Snake Case (stylized as snake_case) names depends on the language.
+> Use of lowercase, camelCase or snake_case names depends on the language.
 
 ### `/sdk/context`
 
diff --git a/specification/logs/README.md b/specification/logs/README.md
index d1dd5fd0318..59cc21833bc 100644
--- a/specification/logs/README.md
+++ b/specification/logs/README.md
@@ -88,7 +88,7 @@ Distributed tracing introduced the notion of trace context propagation.
 
 Fundamentally, though, nothing prevents the logs to adopt the same context
 propagation concepts. If the recorded logs contained trace context identifiers
-(such as trace and span ids or user-defined baggage) it would result
+(such as trace and span IDs or user-defined baggage) it would result
 in much richer correlation between logs and traces, as well as correlation
 between logs emitted by different components of a distributed system. This would
 make logs significantly more valuable in distributed systems.
@@ -185,7 +185,7 @@ Logs can be correlated with the rest of observability data in a few dimensions:
   form of correlation.
 
 - By the **execution context**, also known as the trace context. It is a
-  standard practice to record the execution context (trace and span ids as well
+  standard practice to record the execution context (trace and span IDs as well
   as user-defined context) in the spans. OpenTelemetry extends this practice to
   logs where possible by including [TraceId](data-model.md#field-traceid) and
   [SpanId](data-model.md#field-spanid) in the LogRecords. This allows to
@@ -230,7 +230,7 @@ if included it is highly idiosyncratic and thus difficult to identify, parse and
 use. This makes it nearly impossible to perform trace context correlation for
 system logs. However we can and should automatically enrich system logs with the
 resource context - the information about the host that is available during
-collection. This can include the host name, IP address, container or pod name,
+collection. This can include the hostname, IP address, container or pod name,
 etc. This information should be added to the Resource field of collected log
 data.
 
@@ -284,7 +284,7 @@ to OpenTelemetry Collector where the logs can be further processed and enriched.
 These are applications that are created in-house. People tasked with setting up
 log collection infrastructure sometimes are able to modify these applications to
 alter how logs are written and what information is included in the logs. For
-example, the application’s log formatters may be reconfigured to output json
+example, the application’s log formatters may be reconfigured to output JSON
 instead of plain text and by doing so help improve the reliability of log
 collection.
 
@@ -296,8 +296,8 @@ required.
 As opposed to manual efforts we have an interesting opportunity to "upgrade"
 application logs in a less laborious way by providing full or semi
 auto-instrumenting solutions that modify trace logging libraries used by the
-application to automatically output the trace context such as the trace id or
-span id with every log statement. The trace context can be automatically
+application to automatically output the trace context such as the trace ID or
+span ID with every log statement. The trace context can be automatically
 extracted from incoming requests if standard compliant request propagation is
 used, e.g. via [W3C TraceContext](https://www.w3.org/TR/trace-context/). In
 addition, the requests outgoing from the application may be injected with the
@@ -320,7 +320,7 @@ rotation is used, optionally also parse the logs to convert them into more
 structured formats. Parsing requires support for different parser types, which
 can also be configured to parse custom formats as well as ability to add custom
 parsers. Examples of common formats that parsers need to support are: CSV,
-Common Log Format, Labeled Tab-separated Values (LTSV), Key/Value Pair format,
+Common Log Format, Labeled Tab-separated Values (LTSV), key-value Pair format,
 JSON, etc. To support this approach OpenTelemetry recommends to collect logs
 using OpenTelemetry
 [Collector](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/filelogreceiver).
@@ -404,7 +404,7 @@ Applications have several options for emitting logs:
    that a language can provide a more convenient [ergonomic API](./api.md#ergonomic-api).
 
 Regardless of the approach, emitted logs are automatically augmented by
-application-specific resource context (e.g. process id, programming language,
+application-specific resource context (e.g. process ID, programming language,
 logging library name and version, etc). Full correlation across all context
 dimensions will be available for these logs.
 
@@ -454,12 +454,12 @@ auto-instrumented logging statements will do the following:
 - Read incoming trace context (this is part of broader instrumentation that
   auto-instrumenting libraries perform).
 
-- Configure logging libraries to use trace id and span id fields from request
+- Configure logging libraries to use trace ID and span ID fields from request
   context as logging context and automatically include them in all logged
   statements.
 
 This is possible to do for certain languages (e.g. in Java) and we can reuse
-[existing open-source libraries](https://docs.datadoghq.com/tracing/other_telemetry/connect_logs_and_traces/java/)
+[existing open source libraries](https://docs.datadoghq.com/tracing/other_telemetry/connect_logs_and_traces/java/)
 that do this.
 
 A further optional modification would be to auto-instrument loggers to send logs
diff --git a/specification/logs/data-model-appendix.md b/specification/logs/data-model-appendix.md
index 0edc9f146c7..c8e0bdf597a 100644
--- a/specification/logs/data-model-appendix.md
+++ b/specification/logs/data-model-appendix.md
@@ -52,7 +52,7 @@ this data model.
   <tr>
     <td>FACILITY</td>
     <td>enum</td>
-    <td>Describes where the event originated. A predefined list of Unix processes. Part of event source identity. Example: <code>mail system</code></td>
+    <td>Describes where the event originated. A predefined list of UNIX processes. Part of event source identity. Example: <code>mail system</code></td>
     <td>`Attributes["syslog.facility"]`</td>
   </tr>
   <tr>
@@ -733,7 +733,7 @@ When mapping from the unified model to HEC, we apply this additional mapping:
   <tr>
     <td>host.name</td>
     <td>string</td>
-    <td>Name of the host.<br>It may contain what hostname returns on Unix systems, the fully qualified, or a name specified by the user. </td>
+    <td>Name of the host.<br>It may contain what hostname returns on UNIX systems, the fully qualified, or a name specified by the user. </td>
     <td>`Resource["host.name"]`</td>
   </tr>
   <tr>
diff --git a/specification/logs/data-model.md b/specification/logs/data-model.md
index ff2da244437..ee28600a747 100644
--- a/specification/logs/data-model.md
+++ b/specification/logs/data-model.md
@@ -164,8 +164,8 @@ Here is the list of fields in a log record:
 | ---------- | ----------- |
 | Timestamp | Time when the event occurred. |
 | ObservedTimestamp | Time when the event was observed. |
-| TraceId | Request trace id. |
-| SpanId | Request span id. |
+| TraceId | Request trace ID. |
+| SpanId | Request span ID. |
 | TraceFlags | W3C trace flag. |
 | SeverityText | The severity text (also known as log level). |
 | SeverityNumber | Numerical value of the severity. |
@@ -179,7 +179,7 @@ Below is the detailed description of each field.
 
 ### Field: `Timestamp`
 
-Type: Timestamp, uint64 nanoseconds since Unix epoch.
+Type: Timestamp, uint64 nanoseconds since UNIX epoch.
 
 Description: Time when the event occurred measured by the origin clock, i.e. the
 time at the source. This field is optional, it may be missing if the source
@@ -187,7 +187,7 @@ timestamp is unknown.
 
 ### Field: `ObservedTimestamp`
 
-Type: Timestamp, uint64 nanoseconds since Unix epoch.
+Type: Timestamp, uint64 nanoseconds since UNIX epoch.
 
 Description: Time when the event was observed by the collection system. For
 events that originate in OpenTelemetry (e.g. using OpenTelemetry Logging SDK)
@@ -209,16 +209,16 @@ timestamp internally the following logic is recommended:
 
 Type: byte sequence.
 
-Description: Request trace id as defined in
+Description: Request trace ID as defined in
 [W3C Trace Context](https://www.w3.org/TR/trace-context/#trace-id). Can be set
-for logs that are part of request processing and have an assigned trace id. This
+for logs that are part of request processing and have an assigned trace ID. This
 field is optional.
 
 #### Field: `SpanId`
 
 Type: byte sequence.
 
-Description: Span id. Can be set for logs that are part of a particular
+Description: Span ID. Can be set for logs that are part of a particular
 processing span. If SpanId is present TraceId SHOULD be also present. This field
 is optional.
 
diff --git a/specification/metrics/README.md b/specification/metrics/README.md
index 669f507ab13..be3cf295077 100644
--- a/specification/metrics/README.md
+++ b/specification/metrics/README.md
@@ -78,7 +78,7 @@ processors and exporters.
 
 OpenTelemetry requires a [separation of the API from the
 SDK](../library-guidelines.md#requirements), so that different SDKs can be
-configured at run time. Please refer to the overall [OpenTelemetry
+configured at runtime. Please refer to the overall [OpenTelemetry
 SDK](../overview.md#sdk) concept for more information.
 
 #### Programming Model
diff --git a/specification/metrics/data-model.md b/specification/metrics/data-model.md
index e1c83bc3363..e36e1a3497e 100644
--- a/specification/metrics/data-model.md
+++ b/specification/metrics/data-model.md
@@ -85,7 +85,7 @@ model supports reliability and statelessness controls, through the choice of
 cumulative and delta transport. The model supports cost controls, through
 spatial and temporal reaggregation.
 
-The OpenTelemetry collector is designed to accept metrics data in a number of
+The OpenTelemetry Collector is designed to accept metrics data in a number of
 formats, transport data using the OpenTelemetry data model, and then export into
 existing systems. The data model can be unambiguously translated into the
 Prometheus Remote Write protocol without loss of features or semantics, through
@@ -177,7 +177,7 @@ breadth of OTel metrics usage.
     - With cumulative temporality: stateful collector
 7. OTel SDK exports directly to 3P backend
 
-These are considered the "core" use-cases used to analyze tradeoffs and design
+These are considered the "core" use-cases used to analyze trade-offs and design
 decisions within the metrics data model.
 
 ### Out of Scope Use-cases
@@ -433,7 +433,7 @@ start):
 
 ![Cumulative Sum](img/model-cumulative-sum.png)
 
-There are various tradeoffs between using Delta vs. Cumulative aggregation, in
+There are various trade-offs between using Delta vs. Cumulative aggregation, in
 various use cases, e.g.:
 
 - Detecting process restarts
@@ -441,7 +441,7 @@ various use cases, e.g.:
 - Push vs. Pull based metric reporting
 
 OTLP supports both models, and allows APIs, SDKs and users to determine the
-best tradeoff for their use case.
+best trade-off for their use case.
 
 ### Gauge
 
@@ -679,10 +679,10 @@ which scales can be usefully applied.  Regardless of scale, producers
 SHOULD ensure that the index of any encoded bucket falls within the
 range of a signed 32-bit integer.  This recommendation is applied to
 limit the width of integers used in standard processing pipelines such
-as the OpenTelemetry collector.  The wire-level protocol could be
-extended for 64-bit bucket indices in a future release.
+as the OpenTelemetry Collector.  The wire-level protocol could be
+extended for 64-bit bucket indexes in a future release.
 
-Producers use a mapping function to compute bucket indices.  Producers
+Producers use a mapping function to compute bucket indexes.  Producers
 are presumed to support IEEE double-width floating-point numbers with
 11-bit exponent and 52-bit significand.  The pseudo-code below for
 mapping values to exponents refers to the following constants:
@@ -718,8 +718,8 @@ reference implementations.
 For scale zero, the index of a value equals its normalized base-2
 exponent, meaning the value of *exponent* in the base-2 fractional
 representation `1._significand_ * 2**_exponent_`.  Normal IEEE 754
-double-width floating point values have indices in the range
-`[-1022, +1023]` and subnormal values have indices in the range
+double-width floating point values have indexes in the range
+`[-1022, +1023]` and subnormal values have indexes in the range
 `[-1074, -1023]`.  This may be written as:
 
 ```golang
@@ -792,7 +792,7 @@ func MapToIndexScale0(value float64) int {
 For negative scales, the index of a value equals the normalized
 base-2 exponent (as by `MapToIndexScale0()` above) shifted to the right
 by `-scale`.  Note that because of sign extension, this shift performs
-correct rounding for the negative indices.  This may be written as:
+correct rounding for the negative indexes.  This may be written as:
 
 ```golang
 // MapToIndexNegativeScale computes a bucket index for scales <= 0.
@@ -892,7 +892,7 @@ Implementations are expected to verify that their mapping function and
 inverse mapping function are correct near the lowest and highest IEEE
 floating point values.  A mathematically correct formula may produce
 the wrong result, because of accumulated floating point calculation error
-or underflow/overflow of intermediate results.  In the Golang
+or underflow/overflow of intermediate results.  In the Go
 reference implementation, for example, the above formula computes
 `+Inf` for the maximum-index bucket.  In this case, it is appropriate
 to subtract `1<<scale` from the index and multiply the result by `2`.
@@ -906,7 +906,7 @@ func LowerBoundary(index, scale int) float64 {
 }
 ```
 
-In the Golang reference implementation, for example, the above formula
+In the Go reference implementation, for example, the above formula
 does not accurately compute the lower boundary of the minimum-index
 bucket (it is a subnormal value).  In this case, it is appropriate to
 add `1<<scale` to the index and divide the result by `2`.
@@ -937,14 +937,14 @@ such values counted in the adjacent buckets.
 
 #### ExponentialHistogram: Consumer Recommendations
 
-ExponentialHistogram bucket indices are expected to map into buckets
+ExponentialHistogram bucket indexes are expected to map into buckets
 where both the upper and lower boundaries can be represented
 using IEEE 754 double-width floating point values.  Consumers MAY
 round the unrepresentable boundary of a partially representable bucket
 index to the nearest representable value.
 
 Consumers SHOULD reject ExponentialHistogram data with `scale` and
-bucket indices that overflow or underflow this representation.
+bucket indexes that overflow or underflow this representation.
 Consumers that reject such data SHOULD warn the user through error
 logging that out-of-range data was received.
 
diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md
index 9a51635c050..f5586f677a1 100644
--- a/specification/metrics/sdk.md
+++ b/specification/metrics/sdk.md
@@ -1068,8 +1068,8 @@ information:
 - The `time` the API call was made to record a `Measurement`.
 - The set of [Attributes](../common/README.md#attribute) associated with the
   `Measurement` not already included in a metric data point.
-- The associated [trace id and span
-  id](../trace/api.md#retrieving-the-traceid-and-spanid) of the active [Span
+- The associated [trace ID and span
+  ID](../trace/api.md#retrieving-the-traceid-and-spanid) of the active [Span
   within Context](../trace/api.md#determining-the-parent-span-from-a-context) of
   the `Measurement` at API call time.
 
@@ -1092,7 +1092,7 @@ Then an exemplar output in OTLP would consist of:
 - The `time` when the `add` method was called.
 - The `Attributes` of `{"Z": "z-value"}`, as these are not preserved in the
   resulting metric point.
-- The trace/span id for the `makeRequest` span.
+- The trace/span ID for the `makeRequest` span.
 
 While the metric data point for the counter would carry the attributes `X` and
 `Y`.
diff --git a/specification/metrics/supplementary-guidelines.md b/specification/metrics/supplementary-guidelines.md
index 589034107c0..48fa01eaaeb 100644
--- a/specification/metrics/supplementary-guidelines.md
+++ b/specification/metrics/supplementary-guidelines.md
@@ -90,11 +90,11 @@ middle. Here are some examples:
 * The server temperature is non-additive. The temperatures in the table below
   add up to `226.2`, but this value has no practical meaning.
 
-  | Host Name | Temperature (F) |
-  | --------- | --------------- |
-  | MachineA  | 58.8            |
-  | MachineB  | 86.1            |
-  | MachineC  | 81.3            |
+  | Hostname | Temperature (F) |
+  | -------- | --------------- |
+  | MachineA | 58.8            |
+  | MachineB | 86.1            |
+  | MachineC | 81.3            |
 
 * The mass of planets is additive, the value `1.18e25` (`3.30e23 + 6.42e23 +
   4.87e24 + 5.97e24`) means the combined mass of terrestrial planets in the
diff --git a/specification/overview.md b/specification/overview.md
index 5d802ede27e..c2d5de91c4a 100644
--- a/specification/overview.md
+++ b/specification/overview.md
@@ -109,7 +109,7 @@ A distributed trace is a set of events, triggered as a result of a single
 logical operation, consolidated across various components of an application. A
 distributed trace contains events that cross process, network and security
 boundaries. A distributed trace may be initiated when someone presses a button
-to start an action on a website - in this example, the trace will represent
+to start an action on a site - in this example, the trace will represent
 calls made between the downstream services that handled the chain of requests
 initiated by this button being pressed.
 
@@ -178,15 +178,15 @@ propagated from parent to child **Spans**.
   all processes.
 - **SpanId** is the identifier for a span. It is globally unique with
   practically sufficient probability by being made as 8 randomly generated
-  bytes. When passed to a child Span this identifier becomes the parent span id
+  bytes. When passed to a child Span this identifier becomes the parent span ID
   for the child **Span**.
 - **TraceFlags** represents the options for a trace. It is represented as 1
   byte (bitmap).
   - Sampling bit -  Bit to represent whether trace is sampled or not (mask
     `0x1`).
-- **Tracestate** carries tracing-system specific context in a list of key value
+- **Tracestate** carries tracing-system specific context in a list of key-value
   pairs. **Tracestate** allows different vendors propagate additional
-  information and inter-operate with their legacy Id formats. For more details
+  information and inter-operate with their legacy ID formats. For more details
   see [this](https://www.w3.org/TR/trace-context/#tracestate-header).
 
 ### Links between spans
@@ -220,10 +220,10 @@ scenarios.
 OpenTelemetry allows recording raw measurements or metrics with predefined
 aggregations and a [set of attributes](common/README.md#attribute).
 
-Using the OpenTelemetry API to record raw measurements gives end-users the
+Using the OpenTelemetry API to record raw measurements gives end users the
 flexibility to choose the aggregation algorithm for a given metric. This functionality
 is particularly useful in client libraries such as gRPC, where it enables the
-recording of raw measurements like "server_latency" or "received_bytes." End-users
+recording of raw measurements like "server_latency" or "received_bytes." end users
 then have the autonomy to decide on the aggregation method for these raw measurements,
 options for which range from straightforward averages to more complex histogram calculations.
 
@@ -352,7 +352,7 @@ The Propagators API currently defines one `Propagator` type:
 
 ## Collector
 
-The OpenTelemetry collector is a set of components that can collect traces,
+The OpenTelemetry Collector is a set of components that can collect traces,
 metrics and eventually other telemetry data (e.g. logs) from processes
 instrumented by OpenTelemetry or other monitoring/tracing libraries (Jaeger,
 Prometheus, etc.), do aggregation and smart sampling, and export traces and
@@ -360,7 +360,7 @@ metrics to one or more monitoring/tracing backends. The collector will allow to
 enrich and transform collected telemetry (e.g. add additional attributes or
 scrub personal information).
 
-The OpenTelemetry collector has two primary modes of operation: Agent (a daemon
+The OpenTelemetry Collector has two primary modes of operation: Agent (a daemon
 running locally with the application) and Collector (a standalone running
 service).
 
@@ -387,7 +387,7 @@ to prefix packages with "opentelemetry-instrumentation", followed by the
 instrumented library name itself. Examples include:
 
 * opentelemetry-instrumentation-flask (Python)
-* @opentelemetry/instrumentation-grpc (Javascript)
+* @opentelemetry/instrumentation-grpc (JavaScript)
 
 Instrumentations libraries not hosted by OpenTelemetry should avoid
 potential naming collisions with OpenTelemetry-hosted packages.
@@ -395,6 +395,6 @@ For example, they may prefix instrumentation package name with their company or
 project name:
 
 * {company}-opentelemetry-instrumentation-{component} (Python)
-* @{company}/opentelemetry-instrumentation-{component} (Javascript)
+* @{company}/opentelemetry-instrumentation-{component} (JavaScript)
 
 See [Instrumentation Library](glossary.md#instrumentation-library) for more information.
diff --git a/specification/performance.md b/specification/performance.md
index 46fb2960f41..ee3e9f17d43 100644
--- a/specification/performance.md
+++ b/specification/performance.md
@@ -6,18 +6,18 @@ This document defines common principles that will help designers create OpenTele
 
 Here are the key principles:
 
-- **Library should not block end-user application by default.**
+- **Library should not block end user application by default.**
 - **Library should not consume unbounded memory resource.**
 
-Although there are inevitable overhead to achieve monitoring, API should not degrade the end-user application as possible. So that it should not block the end-user application nor consume too much memory resource.
+Although there are inevitable overhead to achieve monitoring, API should not degrade the end user application as possible. So that it should not block the end user application nor consume too much memory resource.
 
 See also [Concurrency and Thread-Safety](library-guidelines.md#concurrency-and-thread-safety) if the implementation supports concurrency.
 
-### Tradeoff between non-blocking and memory consumption
+### Trade-off between non-blocking and memory consumption
 
-Incomplete asynchronous I/O tasks or background tasks may consume memory to preserve their state. In such a case, there is a tradeoff between dropping some tasks to prevent memory starvation and keeping all tasks to prevent information loss.
+Incomplete asynchronous I/O tasks or background tasks may consume memory to preserve their state. In such a case, there is a trade-off between dropping some tasks to prevent memory starvation and keeping all tasks to prevent information loss.
 
-If there is such tradeoff in OpenTelemetry client, it should provide the following options to end-user:
+If there is such trade-off in OpenTelemetry client, it should provide the following options to end user:
 
 - **Prevent information loss**: Preserve all information but possible to consume many resources
 - **Prevent blocking**: Dropping some information under overwhelming load and show warning log to inform when information loss starts and when recovered
@@ -25,17 +25,17 @@ If there is such tradeoff in OpenTelemetry client, it should provide the followi
   - Better to provide metric that represents effective sampling ratio
   - OpenTelemetry client might provide this option for Logging
 
-### End-user application should be aware of the size of logs
+### End user application should be aware of the size of logs
 
-Logging could consume much memory by default if the end-user application emits too many logs. This default behavior is intended to preserve logs rather than dropping it. To make resource usage bounded, the end-user should consider reducing logs that are passed to the exporters.
+Logging could consume much memory by default if the end user application emits too many logs. This default behavior is intended to preserve logs rather than dropping it. To make resource usage bounded, the end user should consider reducing logs that are passed to the exporters.
 
-Therefore, the OpenTelemetry client should provide a way to filter logs to capture by OpenTelemetry. End-user applications may want to log so much into log file or stdout (or somewhere else) but not want to send all of the logs to OpenTelemetry exporters.
+Therefore, the OpenTelemetry client should provide a way to filter logs to capture by OpenTelemetry. End user applications may want to log so much into log file or stdout (or somewhere else) but not want to send all of the logs to OpenTelemetry exporters.
 
 In a documentation of the OpenTelemetry client, it is a good idea to point out that too many logs consume many resources by default then guide how to filter logs.
 
 ### Shutdown and explicit flushing could block
 
-The OpenTelemetry client could block the end-user application when it shut down. On shutdown, it has to flush data to prevent information loss. The OpenTelemetry client should support user-configurable timeout if it blocks on shut down.
+The OpenTelemetry client could block the end user application when it shut down. On shutdown, it has to flush data to prevent information loss. The OpenTelemetry client should support user-configurable timeout if it blocks on shut down.
 
 If the OpenTelemetry client supports an explicit flush operation, it could block also. But should support a configurable timeout.
 
diff --git a/specification/resource/README.md b/specification/resource/README.md
index e8ff7239123..94009584626 100644
--- a/specification/resource/README.md
+++ b/specification/resource/README.md
@@ -64,7 +64,7 @@ including more than one entity, like:
 
 - A process
 - A container
-- A kubernetes pod name
+- A Kubernetes pod name
 - A namespace
 - A deployment
 
diff --git a/specification/schemas/README.md b/specification/schemas/README.md
index 794b0e0d037..62bb9e8b34d 100644
--- a/specification/schemas/README.md
+++ b/specification/schemas/README.md
@@ -228,10 +228,10 @@ time with OpenTelemetry Collector's schema translation processor).
 
 ## Schema Version Number
 
-Version number follows the MAJOR.MINOR.PATCH format, similar to semver 2.0.
+Version number follows the MAJOR.MINOR.PATCH format, similar to SemVer 2.0.
 
 Version numbers use the [ordering rules](https://semver.org/#spec-item-11)
-defined by semver 2.0 specification. See how ordering is used in the
+defined by SemVer 2.0 specification. See how ordering is used in the
 [Order of Transformations](file_format_v1.1.0.md#order-of-transformations). Other than the ordering
 rules the schema version numbers do not carry any other semantic meaning.
 
diff --git a/specification/specification-principles.md b/specification/specification-principles.md
index 06309615e95..017ca8b5cc3 100644
--- a/specification/specification-principles.md
+++ b/specification/specification-principles.md
@@ -47,7 +47,7 @@ The specification is useless without the ecosystem it enables. Changes should
 focus on real world use cases, and real user needs. Additionally, changes should
 be implementable across the entire OpenTelemetry ecosystem.
 
-This means proposals should think "end to end" not "add this one little thing".
+This means proposals should think "end-to-end" not "add this one little thing".
 
 Projects and proposals should provide prototypes or implementations
 before changes are made to the Specification.
diff --git a/specification/trace/api.md b/specification/trace/api.md
index ca2ebff590a..dba798a1849 100644
--- a/specification/trace/api.md
+++ b/specification/trace/api.md
@@ -73,7 +73,7 @@ The representation of those values is language specific.
 
 #### Timestamp
 
-A timestamp is the time elapsed since the Unix epoch.
+A timestamp is the time elapsed since the UNIX epoch.
 
 * The minimal precision is milliseconds.
 * The maximal precision is nanoseconds.
@@ -277,14 +277,14 @@ When extracting a `SpanContext` through the [Propagators API](../context/api-pro
 
 ### TraceState
 
-`TraceState` is a part of [`SpanContext`](./api.md#spancontext), represented by an immutable list of string key/value pairs and
+`TraceState` is a part of [`SpanContext`](./api.md#spancontext), represented by an immutable list of string key-value pairs and
 formally defined by the [W3C Trace Context specification](https://www.w3.org/TR/trace-context/#tracestate-header).
 Tracing API MUST provide at least the following operations on `TraceState`:
 
 * Get value for a given key
-* Add a new key/value pair
+* Add a new key-value pair
 * Update an existing value for a given key
-* Delete a key/value pair
+* Delete a key-value pair
 
 These operations MUST follow the rules described in the [W3C Trace Context specification](https://www.w3.org/TR/trace-context/#mutating-the-tracestate-field).
 All mutating operations MUST return a new `TraceState` with the modifications applied.
@@ -349,7 +349,7 @@ first sub-operation, and an end time of when the final sub-operation is complete
 This includes:
 
 - receiving the data from the request
-- parsing of the data (e.g. from a binary or json format)
+- parsing of the data (e.g. from a binary or JSON format)
 - any middleware or additional processing logic
 - business logic
 - construction of the response
diff --git a/specification/trace/sdk.md b/specification/trace/sdk.md
index 0451ddbf0d7..651eb4a3fa1 100644
--- a/specification/trace/sdk.md
+++ b/specification/trace/sdk.md
@@ -61,7 +61,7 @@ weight: 3
     + [Presumption of TraceID randomness](#presumption-of-traceid-randomness)
     + [IdGenerator randomness](#idgenerator-randomness)
 - [Span Limits](#span-limits)
-- [Id Generators](#id-generators)
+- [ID Generators](#id-generators)
   * [IdGenerator randomness](#idgenerator-randomness-1)
 - [Span processor](#span-processor)
   * [Interface definition](#interface-definition)
@@ -591,7 +591,7 @@ Optional parameters:
 
 [Jaeger remote sampler][jaeger-remote-sampling] allows remotely controlling the sampling configuration for the SDKs. The sampling configuration is periodically loaded from the backend (see [Remote Sampling API][jaeger-remote-sampling-api]), where it can be managed by operators via configuration files or even automatically calculated (see [Adaptive Sampling][jaeger-adaptive-sampling]). The sampling configuration retrieved by the remote sampler can instruct it to  use either a single sampling method for the whole service (e.g., `TraceIdRatioBased`), or different methods for different endpoints (span names), for example, sample `/product` endpoint at 10%, `/admin` endpoint at 100%, and never sample `/metrics` endpoint.
 
-The full Protobuf definition can be found at [jaegertracing/jaeger-idl/api_v2/sampling.proto](https://github.com/jaegertracing/jaeger-idl/blob/main/proto/api_v2/sampling.proto).
+The full protobuf definition can be found at [jaegertracing/jaeger-idl/api_v2/sampling.proto](https://github.com/jaegertracing/jaeger-idl/blob/main/proto/api_v2/sampling.proto).
 
 The following configuration properties should be available when creating the sampler:
 
@@ -871,7 +871,7 @@ that an attribute, event, or link was discarded due to such a limit.
 To prevent excessive logging, the message MUST be printed at most once per
 span (i.e., not per discarded attribute, event, or link).
 
-## Id Generators
+## ID Generators
 
 The SDK MUST by default randomly generate both the `TraceId` and the `SpanId`.
 
@@ -879,7 +879,7 @@ The SDK MUST provide a mechanism for customizing the way IDs are generated for
 both the `TraceId` and the `SpanId`.
 
 The SDK MAY provide this functionality by allowing custom implementations of
-an interface like the java example below (name of the interface MAY be
+an interface like the Java example below (name of the interface MAY be
 `IdGenerator`, name of the methods MUST be consistent with
 [SpanContext](./api.md#retrieving-the-traceid-and-spanid)), which provides
 extension points for two methods, one to generate a `SpanId` and one for `TraceId`.
@@ -892,7 +892,7 @@ public interface IdGenerator {
 ```
 
 Additional `IdGenerator` implementing vendor-specific protocols such as AWS
-X-Ray trace id generator MUST NOT be maintained or distributed as part of the
+X-Ray trace ID generator MUST NOT be maintained or distributed as part of the
 Core OpenTelemetry repositories.
 
 ### IdGenerator randomness
diff --git a/specification/trace/tracestate-handling.md b/specification/trace/tracestate-handling.md
index 4b0a6ef03cc..2b4a3d85e65 100644
--- a/specification/trace/tracestate-handling.md
+++ b/specification/trace/tracestate-handling.md
@@ -14,7 +14,7 @@ linkTitle: TraceState
 - [Key](#key)
 - [Value](#value)
 - [Setting values](#setting-values)
-- [Pre-defined OpenTelemetry sub-keys](#pre-defined-opentelemetry-sub-keys)
+- [Predefined OpenTelemetry sub-keys](#predefined-opentelemetry-sub-keys)
   * [Sampling threshold value `th`](#sampling-threshold-value-th)
   * [Explicit randomness value `rv`](#explicit-randomness-value-rv)
 
@@ -100,7 +100,7 @@ if ok {
 }
 ```
 
-## Pre-defined OpenTelemetry sub-keys
+## Predefined OpenTelemetry sub-keys
 
 The following values have been defined by OpenTelemetry.
 
diff --git a/specification/upgrading.md b/specification/upgrading.md
index 07010d06cd9..0c024baa952 100644
--- a/specification/upgrading.md
+++ b/specification/upgrading.md
@@ -97,7 +97,7 @@ separate version numbers.
 ### API changes
 
 When new functionality is added to the OpenTelemetry API, a new minor version of
-the API is released. These API changes are always additive and backwards compatible
+the API is released. These API changes are always additive and backward compatible
 from the perspective of existing Instrumentation packages which import and call
 prior versions. Instrumentation written against all prior minor versions of the
 API continues to work, and may be composed together into the same application without
diff --git a/specification/versioning-and-stability.md b/specification/versioning-and-stability.md
index 0ce2dd688ba..2e5e3ea1d08 100644
--- a/specification/versioning-and-stability.md
+++ b/specification/versioning-and-stability.md
@@ -41,7 +41,7 @@ In this document, the terms "OpenTelemetry" and "language implementations" both
 These terms do not refer to the specification or the Collector in this document.
 
 Each language implementation MUST take these versioning and stability requirements, and produce a language-specific document which details how these requirements will be met.
-This document MUST be placed in the root of each repo and named `VERSIONING` or `VERSIONING.md`.
+This document MUST be placed in the root of each repository and named `VERSIONING` or `VERSIONING.md`.
 
 ## Design goals
 
@@ -110,7 +110,7 @@ Languages which ship binary artifacts SHOULD offer [ABI compatibility](glossary.
 
 #### SDK Stability
 
-Public portions of SDK packages MUST remain backwards compatible.
+Public portions of SDK packages MUST remain backward compatible.
 There are two categories of public features: **plugin interfaces** and **constructors**.
 A plugin interface is an extension point provided by the SDK which is intended to be implemented by end users in order to customize SDK behaviors.
 Examples of plugins interfaces include SpanProcessor, Exporter, and Sampler.
@@ -141,7 +141,7 @@ manner (e.g. by providing default implementations). Hereby, backwards-compatible
 the plugin interfaces MUST continue to be possible to use with newer versions of the SDK without making changes to the end user's code.
 For languages that commonly share code via binary artifacts, e.g. Java, backwards-compatible means that end user's code that implements plugin interfaces MUST continue to be possible to use with newer minor or patch versions without recompiling the end user's code.
 
-If this backwards compatible addition of methods to interfaces is not possible for a language,
+If this backward compatible addition of methods to interfaces is not possible for a language,
 the language maintainers SHOULD still implement the addition using backwards-compatible
 workarounds without incrementing the major version.
 For example, a possible workaround might be to add a new interface instead of extending the existing one and accept the
@@ -173,7 +173,7 @@ in [Telemetry Stability](telemetry-stability.md).) The goal is to ensure users c
 update to the latest version of OpenTelemetry, and not be held back by the
 plugins that they depend on.
 
-Public portions of contrib packages (constructors, configuration, interfaces) SHOULD remain backwards compatible.
+Public portions of contrib packages (constructors, configuration, interfaces) SHOULD remain backward compatible.
 
 Languages which ship binary artifacts SHOULD offer [ABI compatibility](glossary.md#abi-compatibility) for contrib packages.
 
@@ -207,7 +207,7 @@ default configuration, e.g. Samplers, Views, etc.
 Semantic Conventions defines the set of fields in the OTLP data model:
 
 - [Resource](resource/sdk.md)
-  - attribute keys. (The key section of attributes key value pairs)
+  - attribute keys. (The key section of attributes key-value pairs)
   - [Entity References](entities/data-model.md)
     - Entity type
     - Identifier (inherits attribute key guarantees from the resource)
@@ -285,7 +285,7 @@ instrumentations can use schemas to change the instrumentation they produce.
 **Exception:** Some resource attributes are embedded in various locations of the
 Specification, e.g. the `service.*` attributes which are required by SDKs to be
 produced and have corresponding [environment variables defined in general SDK configuration](configuration/sdk-environment-variables.md#general-sdk-configuration). These resource
-attributes MUST NOT be ever changed. They are considered a hard-coded part of
+attributes MUST NOT be ever changed. They are considered a hardcoded part of
 this specification.
 
 In addition to the 3 types of changes described above there are certain types