normalize term for instrumentations

milestones.md

@@ -137,9 +137,9 @@ and languages SDKs will implement OpenTelemetry collector exporter.
 
 ### Getting to release
 
-By end of year the basic language SDKs will be complete and we will begin
+By the end of year the basic language SDKs will be complete and we will begin
 stabilization work. Also OpenCensus can be switched to the OpenTelemetry SDK. As
-well as instrumentation adapters can be implemented. So we will have early
+well as instrumentations can be implemented. So we will have early
 adopters.
 
 By early September we committed to provide a production ready full-featured

specification/api-metrics-user.md

@@ -47,7 +47,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/api-tracing.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

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, instrumentations, 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

@@ -23,16 +23,14 @@ 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
 if it has built-in OpenTelemetry instrumentation.
 
 Example: `io.opentelemetry.contrib.mongodb`.
 
-Synonyms: *Instrumentation Library*, *Integration*.
-
 <a name="name"></a>
 
 ## Tracer Name / Meter Name

specification/overview.md

@@ -266,23 +266,24 @@ 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".
-
-## Code injecting adapters
-
-TODO: fill out as a result of SIG discussion.
+## Instrumentation Libraries
+
+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. These
+instrumentations can be wrapping library APIs that subscribe to library-specific
+callbacks or translators that convert telemetry exposed in other formats into
+opentelemetry models.
+
+When naming these instrumentations, it is recommended to follow the library and
+language standards. For instance, if an instrumentation is implemented as a
+"log appender" - it will probably be called an `appender`.
+
+If there is no established name - the recommendation is to call prefix packages
+with "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)