Fix typos and grammar in docs (#2759)

Author: LorenzNickel

docs/GettingStarted.md

@@ -32,7 +32,7 @@ install` commands are all you need to build the SDK.
 
 One important thing to note is that if you're working on the [code
 generator][codegen], be sure to do a `mvn install` rather than a phase that
-comes earlier such as `compile` or `test` so that the build uses the uses the
+comes earlier such as `compile` or `test` so that the build uses the
 correct code generator JAR (i.e. the one including your changes). When in
 doubt, just use `mvn package`.
 

docs/design/NamingConventions.md

@@ -15,8 +15,8 @@ This page describes the naming conventions, nouns and common terms
 * If the class's primary purpose is to return instances of another class:
   * If the "get" method has no parameters:
     * If the class implements `Supplier`: `{Noun}Supplier` (e.g. `CachedSupplier`)
-    * If the class does not implements `Supplier`: `{Noun}Provider` (e.g. `AwsCredentialsProvider`)
-  * If the "get" method has paramters: `{Noun}Factory` (e.g. `AwsJsonProtocolFactory`)
+    * If the class does not implement `Supplier`: `{Noun}Provider` (e.g. `AwsCredentialsProvider`)
+  * If the "get" method has parameters: `{Noun}Factory` (e.g. `AwsJsonProtocolFactory`)
 
 #### Service-specific classes
 

docs/design/UseOfOptional.md

@@ -10,7 +10,7 @@ This page describes a general guideline for the use of
   - `Optional` SHOULD be used when it is not obvious to a caller whether a
   result will be null, e.g, `public <T> Optional<T> getValueForField(String fieldName, Class<T> clazz)`in [SdkResponse.java](https://github.com/aws/aws-sdk-java-v2/blob/aa161c564c580ced4a0381d3ed7d4d13120916fc/core/sdk-core/src/main/java/software/amazon/awssdk/core/SdkResponse.java#L59-L61)
   - `Optional` MUST NOT be used for "getters" in generated service model classes such as service Builders or POJOs.
-- For memember variables: `Optional` SHOULD NOT be used, e.g., `private final Optional<String> field;`
+- For member variables: `Optional` SHOULD NOT be used, e.g., `private final Optional<String> field;`
 - For method parameters: `Optional` MUST NOT be used, e.g., `private void test(Optional<String> value)`
 
 

docs/design/core/metrics/Design.md

@@ -13,7 +13,7 @@ standard metrics collected by the SDK.
 
 ### Metric Collector
 
-* `MetricCollector` is a typesafe aggregator of of metrics. This is the primary
+* `MetricCollector` is a typesafe aggregator of metrics. This is the primary
   interface through which other SDK components report metrics they emit, using
   the `reportMetric(SdkMetric,Object)` method.
 
@@ -31,7 +31,7 @@ standard metrics collected by the SDK.
   returns an immutable version of the tree formed by the collector and its
   children, which are also represented by `MetricCollection` objects.
 
-  Note that calling `collect()` implies that child collectors are are also
+  Note that calling `collect()` implies that child collectors are also
   collected.
 
 * Each collector has a name. Often this is will be used to describe the class of
@@ -240,12 +240,12 @@ New modules are created to support metrics feature.
 ### metrics-publishers
 * This is a new module that contains implementations of all SDK supported publishers
 * Under this module, a new sub-module is created for each publisher (`cloudwatch-publisher`, `csm-publisher`)
-* Customers has to **explicitly add dependency** on these modules to use the sdk provided publishers
+* Customers have to **explicitly add dependency** on these modules to use the sdk provided publishers
 
 ## Performance
-One of the main tenets for metrics is “Enabling default metrics should have
+One of the main tenets for metrics is "Enabling default metrics should have
 minimal impact on the application performance". The following design choices are
-made to ensure enabling metrics does not effect performance significantly.
+made to ensure enabling metrics does not affect performance significantly.
 
 * When collecting metrics, a No-op metric collector is used if metrics are
   disabled. All methods in this collector are no-op and return immediately.

docs/design/core/metrics/MetricsList.md

@@ -9,7 +9,7 @@
 
 The set of core metrics includes all metrics collected by the core components
 of the SDK. This includes components like SDK service clients,
-request/resposne marshallers and unmarshallers, and signers.
+request/response marshallers and unmarshallers, and signers.
 
 All the in code constants associated with metric below can be found in the
 [`software.amazon.awssdk.core.metrics.CoreMetric`](https://github.com/aws/aws-sdk-java-v2/blob/8c192e3b04892987bf0872f76ba4f65167f3a872/core/sdk-core/src/main/java/software/amazon/awssdk/core/metrics/CoreMetric.java#L24)
@@ -35,7 +35,7 @@ class within `sdk-core`.
 
 The set of HTTP metrics below are collected by components that implement the [HTTP SPI](https://github.com/aws/aws-sdk-java-v2/tree/sdk-metrics-development-2/http-client-spi). Which metrics are collected depends on the specific HTTP library used to implement the SPI; not all libraries will allow the collection of every metric below.
 
-Note that in the context of an SDK client API call, all `HttpClient` collectors are children of `ApiCallAttept`; i.e. the full path to HTTP client metrics for an individual API call attempt is `ApiCall` > `ApiCallAttept` > `HttpClient`.
+Note that in the context of an SDK client API call, all `HttpClient` collectors are children of `ApiCallAttempt`; i.e. the full path to HTTP client metrics for an individual API call attempt is `ApiCall` > `ApiCallAttept` > `HttpClient`.
 
 ### Common HTTP Metrics
 

docs/design/core/presigners/README.md

@@ -226,7 +226,7 @@ public interface GetObjectPresignRequest extends PresignRequest {
 
 public interface PresignRequest {
     /**
-     * The duration for which this presigned request should be valid. After this time has expird,
+     * The duration for which this presigned request should be valid. After this time has expired,
      * attempting to use the presigned request will fail.
      */
     Duration signatureDuration();

docs/design/core/waiters/README.md

@@ -82,10 +82,10 @@ Waiter<DescribeTableResponse> waiter =
          .overrideConfiguration(p -> p.maxAttemps(20).backoffStrategy(BackoffStrategy.defaultStrategy())
          .build();
 
-// run synchronousely 
+// run synchronously 
 WaiterResponse<DescribeTableResponse> response = waiter.run(() -> client.describeTable(describeTableRequest));
 
-// run asychronousely
+// run asynchronously
 CompletableFuture<WaiterResponse<DescribeTableResponse>> responseFuture =
       waiter.runAsync(() -> asyncClient.describeTable(describeTableRequest));
 ```

docs/design/services/s3/transfermanager/README.md

@@ -45,8 +45,8 @@ S3 `S3TransferManager`, a high level library built on the S3 client.
 * The size of resources used by Transfermanager and configured by the user
   should not affect its stability.
 
-  For example, the configured size of a threadpool should be irellevant to its
-  ability to successfuly perform an operation.
+  For example, the configured size of a threadpool should be irrelevant to its
+  ability to successfully perform an operation.
 
   Ref: https://github.com/aws/aws-sdk-java/issues/939
 

docs/design/services/s3/transfermanager/listener/README.md

@@ -95,7 +95,7 @@ Internally, `TransferManager` uses its own implementation of a `ProgressListener
 
 ## Java SDK v2 Background
 
-While v2 does not currently support the concept of a `ProgressListener`, it does make extensive use of `ExecutionInterceptor`s, which offers some similar functionality. The `ExecutionInterceptor` interface is an implementation of the [intercepting filter design pattern](https://en.wikipedia.org/wiki/Intercepting_filter_pattern), which offers an composable way to respond to different events and apply resulting transformations. The key difference here is that `ExecutionInterceptor`s tend to be targeted towards mutating operations, and the interface method names further reinforce this, e.g.: `modifyRequest`, `modifyHttpContent`, etc.
+While v2 does not currently support the concept of a `ProgressListener`, it does make extensive use of `ExecutionInterceptor`s, which offers some similar functionality. The `ExecutionInterceptor` interface is an implementation of the [intercepting filter design pattern](https://en.wikipedia.org/wiki/Intercepting_filter_pattern), which offers a composable way to respond to different events and apply resulting transformations. The key difference here is that `ExecutionInterceptor`s tend to be targeted towards mutating operations, and the interface method names further reinforce this, e.g.: `modifyRequest`, `modifyHttpContent`, etc.
 
 The v2 `ExecutionInterceptor` interface can be summarized as follows: