Review feedback

Author: thompson-tomo

.textlintrc.yml

@@ -25,6 +25,7 @@ rules:
     defaultTerms: true
     skip: []
     exclude:
+      - 'bug[- ]fix(es)?'
       - 'readme(s)?'
       - 'to-?do(s)?(?=[ ,.])'
     terms:
@@ -124,7 +125,7 @@ rules:
       - ['3rd[- ]party', third-party]
       - ['auto[- ]c(onfigur)(es?|ations?)', 'autoc$1$2'] # cSpell:disable-line
       - ['back[- ]end(s)?', 'backend$1']
-      - [bugfix, bug fix]
+      - ['bugfix(es?)', 'bug fix$1']
       - [byte code, bytecode]
       - ['(cloud)-(native)', '$1 $2']
       - [cpp, C++]
@@ -181,3 +182,4 @@ rules:
       # 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

oteps/0143-versioning-and-stability.md

@@ -132,11 +132,11 @@ Most changes to OpenTelemetry result in a minor version bump.
 **Patch version bump**
 Patch versions make no changes which would require recompilation or potentially break application code. The following are examples of patch fixes.
 
-* Bugfixes which don't require minor version bump per rules above.
+* Bug fixes which don't require minor version bump per rules above.
 * Security fixes.
 * Documentation.
 
-Currently, OpenTelemetry does NOT have plans to backport bug and security fixes to prior minor versions. Security and bugfixes are only applied to the latest minor version. We are committed to making it feasible for end users to stay up to date with the latest version of OpenTelemetry.
+Currently, OpenTelemetry does NOT have plans to backport bug and security fixes to prior minor versions. Security and bug fixes are only applied to the latest minor version. We are committed to making it feasible for end users to stay up to date with the latest version of OpenTelemetry.
 
 ## Long Term Support
 

oteps/0147-upgrade-procedures.md

@@ -53,4 +53,4 @@ The primary blocker to upgrading the SDK is out of date Plugins. If a new versio
 
 By following a deprecation pattern with Plugin Interfaces, we create a one year window in which the Plugin ecosystem can upgrade after the release of a new SDK. We believe this is sufficient time for any Plugin which is actively maintained to make an upgrade, and for defunct Plugins to be identified and replaced.
 
-By ensuring that the SDK can be easily upgraded, we also provide a path for application owners and operators to rapidly consume critical bugfixes and security patches, without the need to backport these patches across a large number of prior SDK versions.
+By ensuring that the SDK can be easily upgraded, we also provide a path for application owners and operators to rapidly consume critical bug fixes and security patches, without the need to backport these patches across a large number of prior SDK versions.

oteps/README.md

@@ -36,7 +36,7 @@ In practice, this means that OTEPs should be used for such changes as:
 
 On the other hand, they do not need to be used for such changes as:
 
-- Bugfixes
+- Bug fixes
 - Rephrasing, grammatical fixes, typos, etc.
 - Refactoring
 - Things that affect only a single language or implementation

oteps/entities/0256-entities-data-model.md

@@ -380,7 +380,7 @@ 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

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`
 

specification/upgrading.md

@@ -160,5 +160,5 @@ We believe this is sufficient time for any Plugin which is actively maintained
 to make an upgrade, and for defunct Plugins to be identified and replaced.
 
 By ensuring that the SDK can be easily upgraded, we also provide a path for application
-owners and operators to rapidly consume critical bugfixes and security patches,
+owners and operators to rapidly consume critical bug fixes and security patches,
 without the need to backport these patches across a large number of prior SDK versions.

specification/versioning-and-stability.md

@@ -387,12 +387,12 @@ Most changes to OpenTelemetry clients result in a minor version bump.
 Patch versions make no changes which would require recompilation or potentially break application code.
 The following are examples of patch fixes.
 
-* Bugfixes which don't require minor version bump per rules above.
+* Bug fixes which don't require minor version bump per rules above.
 * Security fixes.
 * Documentation.
 
 Currently, the OpenTelemetry project does NOT have plans to backport bug and security fixes to prior minor versions of the SDK.
-Security and bugfixes MAY only be applied to the latest minor version.
+Security and bug fixes MAY only be applied to the latest minor version.
 We are committed to making it feasible for end users to stay up to date with the latest version of the OpenTelemetry SDK.
 
 ### Language version support