docs(various): fix typos in VISION and ROADMAP (#2875)

Signed-off-by: r <ryanrussell@users.noreply.github.com>
This commit is contained in:
Ryan Russell
2022-05-27 08:51:32 -05:00
committed by GitHub
parent 3a755a632d
commit a929df843e
3 changed files with 5 additions and 5 deletions

View File

@@ -34,7 +34,7 @@ to include them all.
### Categorize ### 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, 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 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 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 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 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 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 should be changed from a question, and the title should be a succinct action to
be taken. For example, a question about an non-existant configuration option be taken. For example, a question about an non-existent configuration option
may be reworded to "Add option to Client to do Zed". may be reworded to "Add option to Client to do Zed".
### Mentoring ### Mentoring

View File

@@ -82,7 +82,7 @@ of `http` and `hyper` are prepared for that, there's two potential problems.
- New HTTP versions - New HTTP versions
- HTTP/3 will require a new transport abstraction. It's not as simple as just using some - 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, `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. 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 - 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. accept a QUIC transport so we can add HTTP/3 support.

View File

@@ -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 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 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 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. suggest reaching for higher-level, _easier_ libraries instead.
Those that stick around after that recommendation are users that wish both to Those that stick around after that recommendation are users that wish both to