Fix typos and linguistic errors in documentation / hacktoberfest (#7494)

Fix typos and linguistic errors in documentation. It's not much, but I'm
happy to help

---------

Signed-off-by: Sebastien Dionne <[email protected]>
Co-authored-by: Tyler Yahn <[email protected]>

Author: survivant

CONTRIBUTING.md

@@ -54,8 +54,8 @@ go get -d go.opentelemetry.io/otel
 (This may print some warning about "build constraints exclude all Go
 files", just ignore it.)
 
-This will put the project in `${GOPATH}/src/go.opentelemetry.io/otel`. You
-can alternatively use `git` directly with:
+This will put the project in `${GOPATH}/src/go.opentelemetry.io/otel`.
+Alternatively, you can use `git` directly with:
 
 ```sh
 git clone https://github.com/open-telemetry/opentelemetry-go
@@ -65,8 +65,7 @@ git clone https://github.com/open-telemetry/opentelemetry-go
 that name is a kind of a redirector to GitHub that `go get` can
 understand, but `git` does not.)
 
-This would put the project in the `opentelemetry-go` directory in
-current working directory.
+This will add the project as `opentelemetry-go` within the current directory.
 
 Enter the newly created directory and add your fork as a new remote:
 
@@ -109,7 +108,7 @@ A PR is considered **ready to merge** when:
 
   This is not enforced through automation, but needs to be validated by the
   maintainer merging.
-  * At least one of the qualified approvals need to be from an
+  * At least one of the qualified approvals needs to be from an
     [Approver]/[Maintainer] affiliated with a different company than the author
     of the PR.
   * PRs introducing changes that have already been discussed and consensus
@@ -166,11 +165,11 @@ guidelines](https://opentelemetry.io/docs/specs/otel/library-guidelines).
 ### Focus on Capabilities, Not Structure Compliance
 
 OpenTelemetry is an evolving specification, one where the desires and
-use cases are clear, but the method to satisfy those uses cases are
+use cases are clear, but the methods to satisfy those use cases are
 not.
 
 As such, Contributions should provide functionality and behavior that
-conforms to the specification, but the interface and structure is
+conforms to the specification, but the interface and structure are
 flexible.
 
 It is preferable to have contributions follow the idioms of the
@@ -217,7 +216,7 @@ about dependency compatibility.
 This project does not partition dependencies based on the environment (i.e.
 `development`, `staging`, `production`).
 
-Only the dependencies explicitly included in the released modules have be
+Only the dependencies explicitly included in the released modules have been
 tested and verified to work with the released code. No other guarantee is made
 about the compatibility of other dependencies.
 
@@ -635,8 +634,8 @@ is not in their root name.
 
 The use of internal packages should be scoped to a single module. A sub-module
 should never import from a parent internal package. This creates a coupling
-between the two modules where a user can upgrade the parent without the child
-and if the internal package API has changed it will fail to upgrade[^3].
+between the two modules where a user can upgrade the parent without the child,
+and if the internal package API has changed, it will fail to upgrade[^3].
 
 There are two known exceptions to this rule:
 
@@ -657,7 +656,7 @@ this.
 
 ### Ignoring context cancellation
 
-OpenTelemetry API implementations need to ignore the cancellation of the context that are
+OpenTelemetry API implementations need to ignore the cancellation of the context that is
 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.
@@ -891,7 +890,7 @@ func (i *instrumentation) record(ctx context.Context, value int64, baseAttrs ...
 
 Pools are most effective when there are many pooled objects of the same sufficiently large size, and the objects are repeatedly used.
 This amortizes the cost of allocation and synchronization.
-Ideally, the pools should be scoped to be used as widely as possible within the component to maximize this efficiency while still ensure correctness.
+Ideally, the pools should be scoped to be used as widely as possible within the component to maximize this efficiency while still ensuring correctness.
 
 [`sync.Pool`]: https://pkg.go.dev/sync#Pool
 
@@ -1079,7 +1078,7 @@ func componentName() attribute.KeyValue {
 ```
 
 The component ID will need to be resettable for deterministic testing.
-If test are in a different package than the component being tested (i.e. a `<component package>_test` package name), use a generated `counter` internal package to manage the counter.
+If tests are in a different package than the component being tested (i.e. a `<component package>_test` package name), use a generated `counter` internal package to manage the counter.
 See [stdouttrace exporter example](./exporters/stdout/stdouttrace/internal/gen.go) for reference.
 
 #### Testing

RELEASING.md

@@ -24,7 +24,7 @@ Ensure things look correct before submitting a pull request to include the addit
 
 ## Breaking changes validation
 
-You can run `make gorelease` that runs [gorelease](https://pkg.go.dev/golang.org/x/exp/cmd/gorelease) to ensure that there are no unwanted changes done in the public API.
+You can run `make gorelease` which runs [gorelease](https://pkg.go.dev/golang.org/x/exp/cmd/gorelease) to ensure that there are no unwanted changes made in the public API.
 
 You can check/report problems with `gorelease` [here](https://golang.org/issues/26420).
 
@@ -62,7 +62,7 @@ Update go.mod for submodules to depend on the new release which will happen in t
     ```
 
 3. Update the [Changelog](./CHANGELOG.md).
-   - Make sure all relevant changes for this release are included and are in language that non-contributors to the project can understand.
+   - Make sure all relevant changes for this release are included and are written in language that non-contributors to the project can understand.
        To verify this, you can look directly at the commits since the `<last tag>`.
 
        ```

VERSIONING.md

@@ -83,7 +83,7 @@ is designed so the following goals can be achieved.
       in either the module path or the import path.
   * In addition to public APIs, telemetry produced by stable instrumentation
     will remain stable and backwards compatible. This is to avoid breaking
-    alerts and dashboard.
+    alerts and dashboards.
   * Modules will be used to encapsulate instrumentation, detectors, exporters,
     propagators, and any other independent sets of related components.
     * Experimental modules still under active development will be versioned at

attribute/encoder.go

@@ -16,7 +16,7 @@ type (
 	// set into a wire representation.
 	Encoder interface {
 		// Encode returns the serialized encoding of the attribute set using
-		// its Iterator. This result may be cached by a attribute.Set.
+		// its Iterator. This result may be cached by an attribute.Set.
 		Encode(iterator Iterator) string
 
 		// ID returns a value that is unique for each class of attribute

bridge/opencensus/doc.go

@@ -40,7 +40,7 @@
 //   - The NewContext method of the OpenCensus Tracer cannot embed an OpenCensus
 //     Span in a context unless that Span was created by that Tracer.
 //   - Conversion of custom OpenCensus Samplers to OpenTelemetry is not
-//     implemented, and An error will be sent to the OpenTelemetry ErrorHandler.
+//     implemented, and an error will be sent to the OpenTelemetry ErrorHandler.
 //
 // There are known limitations to the metric bridge:
 //   - GaugeDistribution-typed metrics are dropped

exporters/stdout/stdoutmetric/encoder.go

@@ -15,7 +15,7 @@ type Encoder interface {
 }
 
 // encoderHolder is the concrete type used to wrap an Encoder so it can be
-// used as a atomic.Value type.
+// used as an atomic.Value type.
 type encoderHolder struct {
 	encoder Encoder
 }

internal/global/meter.go

@@ -105,7 +105,7 @@ type delegatedInstrument interface {
 	setDelegate(metric.Meter)
 }
 
-// instID are the identifying properties of a instrument.
+// instID are the identifying properties of an instrument.
 type instID struct {
 	// name is the name of the stream.
 	name string

metric.go

@@ -11,7 +11,7 @@ import (
 // Meter returns a Meter from the global MeterProvider. The name must be the
 // name of the library providing instrumentation. This name may be the same as
 // the instrumented code only if that code provides built-in instrumentation.
-// If the name is empty, then a implementation defined default name will be
+// If the name is empty, then an implementation defined default name will be
 // used instead.
 //
 // If this is called before a global MeterProvider is registered the returned