normalize term for instrumentations

specification/error-handling.md

@@ -44,7 +44,7 @@ And make a reasonable trade off of the SDK performance and fullness of type chec
 
 ## Self-diagnostics
 
-All OpenTelemetry libraries -- the API, SDK, exporters, instrumentation adapters, etc. -- are encouraged to expose self-troubleshooting metrics, spans, and other telemetry that can be easily enabled and filtered out by default.
+All OpenTelemetry libraries -- the API, SDK, exporters, an instrumentation, etc. -- are encouraged to expose self-troubleshooting metrics, spans, and other telemetry that can be easily enabled and filtered out by default.
 
 One good example of such telemetry is a `Span` exporter that indicates how much time exporters spend uploading telemetry.
 Another example may be a metric exposed by a `SpanProcessor` that describes the current queue size of telemetry data to be uploaded.

specification/glossary.md

@@ -25,15 +25,15 @@ Example: `org.mongodb.client`.
 
 <a name="instrumenting_library"></a>
 
-### Instrumenting Library
+### Instrumentation Library
 
 Denotes the library that provides the instrumentation for a given [Instrumented Library](#instrumented_library).
-*Instrumented Library* and *Instrumenting Library* may be the same library
+*Instrumented Library* and *Insrumentation Library* may be the same library
 if it has built-in OpenTelemetry instrumentation.
 
 Example: `io.opentelemetry.contrib.mongodb`.
 
-Synonyms: *Instrumentation Library*, *Integration*.
+Synonyms: *Instrumentation Library*
 
 <a name="name"></a>
 

specification/metrics/api-user.md

@@ -45,7 +45,7 @@ New `Meter` instances can be created via a `MeterProvider` and its `getMeter` me
 `MeterProvider`s are generally expected to be used as singletons.
 Implementations SHOULD provide a single global default `MeterProvider`. The `getMeter` method expects two string arguments:
 
-- `name` (required): This name must identify the instrumentation library (also referred to as integration, e.g. `io.opentelemetry.contrib.mongodb`)
+- `name` (required): This name must identify the instrumentation library (e.g. `io.opentelemetry.contrib.mongodb`)
   and *not* the instrumented library.
   In case an invalid name (null or empty string) is specified, a working default `Meter` implementation is returned as a fallback
   rather than returning null or throwing an exception.

specification/overview.md

@@ -262,22 +262,29 @@ service).
 Read more at OpenTelemetry Service [Long-term
 Vision](https://github.com/open-telemetry/opentelemetry-collector/blob/master/docs/vision.md).
 
-## Instrumentation adapters
-
-The inspiration of the project is to make every library and application
-manageable out of the box by instrumenting it with OpenTelemetry. However on the
-way to this goal there will be a need to enable instrumentation by plugging
-instrumentation adapters into the library of choice. These adapters can be
-wrapping library APIs, subscribing to the library-specific callbacks or
-translating telemetry exposed in other formats into OpenTelemetry model.
-
-Instrumentation adapters may be called different names. It is often referred as
-plugin, collector or auto-collector, telemetry module, bridge, etc. It is always
-recommended to follow the library and language standards. For instance, if
-instrumentation adapter is implemented as "log appender" - it will probably be
-called an `appender`, not an instrumentation adapter. However if there is no
-established name - the recommendation is to call packages "Instrumentation
-Adapter" or simply "Adapter".
+## Instrumentation Libraries
+
+See [Instrumentation Library](glossary.md#instrumenting_library)
+
+A goal of the project is to enable OpenTelemetry instrumentation on every library
+and application out of the box. To achieve that goal, there is a need to author
+instrumentation libraries on these shared libraries and applications. An
+instrumentation may wrap library APIs, subscribe to library-specific
+callbacks or translators that convert telemetry exposed in other formats into
+OpenTelemetry models.
+
+If the library that is being instrumented has a convention around the naming of
+an integration (e.g. 'middleware' for a web framework), the instrumentation should
+have a name that follows the convention of that library.
+
+If there is no established name, the recommendation is to prefix packages
+with "opentelemetry-instrumentation", followed by the instrumented library name itself.
+
+Here are some example library names that illustrate the OpenTelemetry
+recommendation:
+
+* opentelemetry-instrumentation-flask (Python)
+* @opentelemetry/instrumentation-grpc (Javascript)
 
 ## Code injecting adapters
 

specification/trace/api.md

@@ -88,8 +88,7 @@ Some applications may use multiple `TracerProvider` instances, e.g. to provide
 different settings (e.g. `SpanProcessor`s) to each of those instances and -
 in further consequence - to the `Tracer` instances created by them.
 
-- `name` (required): This name must identify the instrumentation library (also
-  referred to as integration, e.g. `io.opentelemetry.contrib.mongodb`) and *not*
+- `name` (required): This name must identify the instrumentation library (e.g. `io.opentelemetry.contrib.mongodb`) and *not*
   the instrumented library.
   In case an invalid name (null or empty string) is specified, a working
   default Tracer implementation as a fallback is returned rather than returning