diff --git a/text/0235-collections-conventions.md b/text/0235-collections-conventions.md
index 8a44b60c3..cf652fbf5 100644
--- a/text/0235-collections-conventions.md
+++ b/text/0235-collections-conventions.md
@@ -1108,7 +1108,7 @@ These traits will be implemented for: `[T]`, `Vec`, `RingBuf`, `HashMap`, `TreeM
 
 As a general convention, implementation of the `Index` traits will *fail the
 task* if the index is invalid (out of bounds or key not found); they will
-therefor return direct references to values. Any collection implementing `Index`
+therefore return direct references to values. Any collection implementing `Index`
 (resp. `IndexMut`) should also provide a `get` method (resp. `get_mut`) as a
 non-failing variant that returns an `Option` value.
 
diff --git a/text/0517-io-os-reform.md b/text/0517-io-os-reform.md
index 232103be9..a3411b2e3 100644
--- a/text/0517-io-os-reform.md
+++ b/text/0517-io-os-reform.md
@@ -294,7 +294,7 @@ models or nonblocking IO, nor is it a goal for the blocking APIs to eventually
 be used in a nonblocking "mode" or style.
 
 Rather, the hope is that the basic abstractions of files, paths, sockets, and so
-on will eventually be usable directly within an async IO programing model and/or
+on will eventually be usable directly within an async IO programming model and/or
 with nonblocking APIs. This is the case for most existing languages, which offer
 multiple interoperating IO models.
 
diff --git a/text/1636-document_all_features.md b/text/1636-document_all_features.md
index 86963b77f..f991d6caf 100644
--- a/text/1636-document_all_features.md
+++ b/text/1636-document_all_features.md
@@ -115,7 +115,7 @@ Here is the Ember RFC section, with appropriate substitutions and modifications:
 > # How We Teach This
 > What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing Rust patterns, or as a wholly new one?
 >
-> Would the acceptance of this proposal change how Rust is taught to new users at any level?  What additions or changes to the Rust Reference, _The Rust Programing Language_, and/or _Rust by Example_ does it entail?
+> Would the acceptance of this proposal change how Rust is taught to new users at any level?  What additions or changes to the Rust Reference, _The Rust Programming Language_, and/or _Rust by Example_ does it entail?
 >
 > How should this feature be introduced and taught to existing Rust users?
 
diff --git a/text/2103-tool-attributes.md b/text/2103-tool-attributes.md
index 7d646ebb7..8ad98bd6a 100644
--- a/text/2103-tool-attributes.md
+++ b/text/2103-tool-attributes.md
@@ -132,7 +132,7 @@ There will be some opt-in mechanism for crates to declare that they want to
 allow use of a tool's attributes. This might be in the source text (an attribute
 as in #1755 or new syntax, e.g., `extern attribute foo;`) or passed to rustc as
 a command line flag (e.g., `--extern-attr foo`). The exact mechanism is
-deliberately unspecifed.
+deliberately unspecified.
 
 After opting-in to `foo`, a crate can use `foo` as the base of a path in any
 attribute in the crate. E.g., allowing `#[foo::bar]` to be used (but not