fix: name of diag in CHANGELOG

GUIDELINES.md

@@ -165,9 +165,9 @@ To support this use case, you can choose one of the following options:
     ...
     ```
 
-## Diag Channel
+## Diag Logging
 
-The diag channel can be used to troubleshoot issues with instrumentation packages.
+The OpenTelemetry diagnostic logging channel can be used to troubleshoot issues with instrumentation packages.
 
 ### Patching Messages
 
@@ -178,7 +178,7 @@ When OpenTelemetry is installed in a user application, and expected spans are mi
 
 It can also be useful to know when the instrumentation is loaded and patched, to understand the order of operations in the application.
 
-Instrumentation packages should use the `@opentelemetry/instrumentation` package `BaseInstrumentation` class to register patches and unpatch callbacks for specific require/import of the instrumented package, it's dependency or an internal module file. When this mechanism is used, the base class will automatically emit a debug message on instrumentation diag component logger, looking like this:
+Instrumentation packages should use the `@opentelemetry/instrumentation` package `InstrumentationBase` class to register patches and unpatch callbacks for specific require/import of the instrumented package, it's dependency or an internal module file. When this mechanism is used, the base class will automatically emit a debug message on instrumentation diag component logger, looking like this:
 
 ```shell
 @opentelemetry/instrumentation-foo Applying instrumentation patch for module on require hook {
@@ -193,7 +193,7 @@ Instrumentation should not add additional debug messages for triggering the patc
 Instrumentation may add additional patch/unpatch messages for specific functions if it is expected to help in troubleshooting issues with the instrumentation. Few examples:
 
 - If the patch logic is conditional, and user can benefit from ensuring the condition is met and the patch happened. `koa` patching logic examine an object and branch between patching it as router vs middleware, which is applied at runtime. `aws-lambda` will abort patching if the environment is not configured properly.
-- When the patch is not applied directly on a `moduleExports` object in the `BaseInstrumentation` callbacks, but rather from an event in the package, like creating new client instance, registering a listener, etc. `fastify` instrumentation applies a patch when a hook is added to the fastify app instance, which is patched from `moduleExports`.
+- When the patch is not applied directly on a `moduleExports` object in the `InstrumentationBase` callbacks, but rather from an event in the package, like creating new client instance, registering a listener, etc. `fastify` instrumentation applies a patch when a hook is added to the fastify app instance, which is patched from `moduleExports`.
 - In situations where the patch logic is not trivial and it helps to specify patch events in the right context and nuances. `aws-lambda` logs additional properties extracted from the lambda framework and exposes them for troubleshooting.
 
 The cases above are not covered by the base class and offer additional context to the user troubleshooting an issue with the instrumentation.