docs(various): Improve readability

docs/ISSUES.md

@@ -34,7 +34,7 @@ to include them all.
 
 ### Categorize
 
-Once enough information has been gathererd, the issue should be categorized
+Once enough information has been gathered, the issue should be categorized
 with [labels][#labels]. Ideally, most issues should be labelled with an area,
 effort, and severity. An issue _can_ have multiple areas, pick what fits. There
 should be only one severity, and the descriptions of each should help to pick
@@ -47,8 +47,8 @@ maintainer to pick one.
 An optional step when triaging is to adjust the title once more information is
 known. Sometimes an issue starts as a question, and through discussion, it
 turns out to be a feature request, or a bug report. In those cases, the title
-should be changed from a question, and the title should be a succict action to
-be taken. For example, a question about an non-existant configuration option
+should be changed from a question, and the title should be a succinct action to
+be taken. For example, a question about an non-existent configuration option
 may be reworded to "Add option to Client to do Zed".
 
 ### Mentoring

docs/ROADMAP.md

@@ -82,7 +82,7 @@ of `http` and `hyper` are prepared for that, there's two potential problems.
 - New HTTP versions
   - HTTP/3 will require a new transport abstraction. It's not as simple as just using some
     `impl AsyncRead + AsyncWrite`. While HTTP/2 bundled the concept of stream creation internally,
-    and thus could be managed wholy on top of a read-write transport, HTTP/3 is different. Stream
+    and thus could be managed wholly on top of a read-write transport, HTTP/3 is different. Stream
     creation is shifted to the QUIC protocol, and HTTP/3 needs to be able to use that directly.
   - This means the existing `Connection` types for both client and server will not be able to
     accept a QUIC transport so we can add HTTP/3 support.

docs/VISION.md

@@ -70,7 +70,7 @@ have reached for hyper to start with.
 It's likely that these users don't have strong opinions about how an HTTP
 server or client should work, just that it _should_ handle all the things they
 normally assume it would. For these users, it would be best to quickly help
-them compare their own expectations with hyper's capabitilities, and may
+them compare their own expectations with hyper's capabilities, and may
 suggest reaching for higher-level, _easier_ libraries instead.
 
 Those that stick around after that recommendation are users that wish both to