Apply suggestions from code review

Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>

CHANGELOG.md

@@ -21,9 +21,7 @@ This project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.htm
 ### Changed
 
 - Record synchronous measurements when the passed context is canceled instead of dropping in `go.opentelemetry.io/otel/sdk/metric`.
-  If you do not want to make measurment in such scenario then you need to handle it yourself.
-  You can do it e.g. by adding `if ctx.Err() != nil` condition before making the measurement.
-  However, we believe that you rather not want it as the telemetry may be necessary to diagnose a cancellation-related problem. (#4671)
+  If you do not want to make a measurement when the context is cancelled, you need to handle it yourself (e.g  `if ctx.Err() != nil`). (#4671)
 - Improve `go.opentelemetry.io/otel/trace.TraceState`'s performance. (#4722)
 - Improve `go.opentelemetry.io/otel/propagation.TraceContext`'s performance. (#4721)
 - Improve `go.opentelemetry.io/otel/baggage` performance. (#4743)

CONTRIBUTING.md

@@ -591,19 +591,25 @@ this.
 
 [^3]: https://github.com/open-telemetry/opentelemetry-go/issues/3548
 
-### Honoring context cancellation
-
-The implementation of OpenTelemetry API that is responsible for telemetry recording
-(starting a span, making a synchronous metric measurement, emitting a log)
-must not honor the cancelation of the passed context.
-Among other things, the telemetry may be necessary to diagnose a
-cancellation-related problem.
-The context can be used to pass request-scoped values
-such as Trace ID and Span ID.
-
-For other use cases
-(exporting telemetry, force flushing telemetry, shutting down a signal provider)
-the context cancelation should be honored.
+### Ignoring context cancellation
+
+OpenTelemetry API implementations need to ignore the cancellation of the context that are
+passed when recording a value (e.g. starting a span, recording a measurement, emitting a log).
+Recording methods should not return an error describing the cancellation state of the context
+when they complete, nor should they abort any work.
+
+This rule may not apply if the OpenTelemetry specification defines a timeout mechanism for
+the method. In that case the context cancellation can be used for the timeout with the
+restriction that this behavior is documented for the method. Otherwise, timeouts
+are expected to be handled by the user calling the API, not the implementation.
+
+Stoppage of the telemetry pipeline is handled by calling the appropriate `Shutdown` method
+of a provider. It is assumed the context passed from a user is not used for this purpose.
+
+Outside of the direct recording of telemetry from the API (e.g. exporting telemetry,
+force flushing telemetry, shutting down a signal provider) the context cancellation
+should be honored. This means all work done on behalf of the user provided context
+should be canceled.
 
 ## Approvers and Maintainers