grammar adjustments;

proposed/http-client/http-client-meta.md

@@ -3,15 +3,15 @@ HTTP Client Meta Document
 
 ## Summary
 
-HTTP request and responses are the two fundamental objects in web programming.
+HTTP requests and responses are the two fundamental objects in web programming.
 All clients communicating to an external API use some form of HTTP client. Many
 libraries are coupled to one specific client or implement a client and/or adapter
 layer themselves. This leads to bad library design, version conflicts or too much
 code not related to the library domain.
 
 ## Why bother?
 
-Thanks to PSR-7 we know how HTTP requests and responses ideally look like, but nothing
+Thanks to PSR-7 we know how HTTP requests and responses ideally look, but nothing
 defines how a request should be sent and a response received. A common interface for HTTP
 client will allow libraries to be decoupled from specific implementation such as Guzzle.
 
@@ -24,14 +24,14 @@ client will allow libraries to be decoupled from specific implementation such as
 ### Non-Goals
 
 * Support for asynchronous HTTP requests is left for another future PSR;
-* This PSR does not define how to configure a HTTP client. It only specifies the 
+* This PSR does not define how to configure an HTTP client. It only specifies the
   default behaviours;
 * We aim to be neutral about the use of middlewares (PSR-15).
 
 #### Asynchronous HTTP client
 
 The reason asynchronous requests are not covered by this PSR is the lack of a
-common standard for Promises. And a HTTP client PSR should not define its own
+common standard for Promises. And an HTTP client PSR should not define its own
 promises. At the time the HTTP client PSR was written there was no final PSR
 for Promises. 
 
@@ -65,11 +65,11 @@ a contract very similar to each other. The chosen approach is to not let them ex
 because inheritance does not make sense in the domain model. A `RequestException` is simply not a
 `NetworkException`.
 
-Allowing exception to extend a `RequestAwareException` and/or `ResponseAwareException` interface
+Allowing exceptions to extend a `RequestAwareException` and/or `ResponseAwareException` interface
 has been discussed but that is a convenience shortcut that one should not take. One should rather
 catch the specific exceptions and handle them accordingly.
 
-One could be more granular when defining exception. For example, `TimeOutException` and `HostNotFoundException`
+One could be more granular when defining exceptions. For example, `TimeOutException` and `HostNotFoundException`
 could be subtypes of `NetworkException`. The chosen approach is not to define such subtypes because
 the exception handling in a consuming library would in most cases not be different between those exceptions.
 
@@ -87,11 +87,11 @@ exceptions for 4xx and 5xx responses.
 
 The HTTP client PSR has been inspired and created by the [php-http team](https://github.com/orgs/php-http/people).
 Back in 2015, they created HTTPlug as a common interface for HTTP clients.
-They wanted an abstraction that third party libraries can use to not rely
+They wanted an abstraction that third party libraries could use to not rely
 on a specific HTTP client implementation like Guzzle 5, Guzzle 6 or Buzz.
-A stable version was tagged in January 2016 and the project got widely
+A stable version was tagged in January 2016 and the project has been widely
 adopted since then. With over 3 million downloads the next
-two years it was time to convert this "de-facto" standard into a real PSR.
+two years, it was time to convert this "de-facto" standard into a real PSR.
 
 ## People
 

proposed/http-client/http-client.md

@@ -39,11 +39,11 @@ the client MUST NOT throw an exception. For example, response status codes in th
 
 The goal of this PSR is to allow developers to create libraries decoupled from HTTP client
 implementations. This will make libraries more reusable as it reduces the number of
-dependencies and lowers the likelihood to get version conflicts.
+dependencies and lowers the likelihood of version conflicts.
 
-The second goal is that HTTP clients can be replaced as per the
+A second goal is that HTTP clients can be replaced as per the
 [Liskov substitutions principle][Liskov]. This means that all clients MUST behave in the
-same when sending a request.
+same way when sending a request.
 
 ## Interfaces
 
@@ -108,8 +108,8 @@ use Psr\Http\Message\RequestInterface;
  * Exception for when a request failed.
  *
  * Examples:
- *      - Request is invalid (eg. method is missing)
- *      - Runtime request errors (like the body stream is not seekable)
+ *      - Request is invalid (e.g. method is missing)
+ *      - Runtime request errors (e.g. the body stream is not seekable)
  */
 interface RequestException extends ClientException
 {