fix some typos

Author: lqd

src/2025h1/all-hands.md

@@ -16,7 +16,7 @@ It's been too long since we've had a Rust All-Hands. Time to bring it back!
 
 ### The status quo
 
-Previous Rust All-Hands events were very useful and succesful, but after the changes at Mozilla, we haven't had a Rust All-Hands in six years.
+Previous Rust All-Hands events were very useful and successful, but after the changes at Mozilla, we haven't had a Rust All-Hands in six years.
 Meanwhile, the project has grown a lot, making it much harder and expensive to organise a new Rust All-Hands.
 
 A few months ago, when Jack brought up having a new Rust All-Hands in the Leadership Council meeting,
@@ -33,7 +33,7 @@ See https://blog.rust-lang.org/inside-rust/2024/09/02/all-hands.html
 
 ### The "shiny future" we are working towards
 
-The immediate goal is a very succesful and productive Rust All-Hands 2025.
+The immediate goal is a very successful and productive Rust All-Hands 2025.
 Hopefully, this will be the first step towards the larger goal of having regular Rust All-Hands again.
 
 We should be able to use the feedback and lessons learned from this event for the next ones,

src/2025h1/cargo-plumbing.md

@@ -73,11 +73,11 @@ This is exclusively focused on build while other operations may be of interest t
 We can evaluate those commands in the future as they tend to still build off of these same core primitives.
 
 At minimum, later commands in the process would accept output from earlier commands,
-allowing the caller to either replace commands (e.g. custom depedency resolver)
+allowing the caller to either replace commands (e.g. custom dependency resolver)
 or customize the output (e.g. remove `dev-dependencies` from manifests).
 
 Encapsulating stabilized file formats can serve as a starting point for output
-schemas as we already output those and have to deal with stability guarentees
+schemas as we already output those and have to deal with stability guarantees
 around these.
 
 Between planning a build and executing abuild is likely to look like

src/2025h1/min_generic_const_arguments.md

@@ -26,7 +26,7 @@ It is possible to use generic parameters with const generics by using `feature(g
 
 ### The next six months
 
-We have a design for `min_generic_const_args` in mind but would like to validate it through implementation as const generics has a history of unforseen issues showing up during implementation. Therefore we will pursue a prototype implementation in 2025. As a stretch goal, we will attempt to review the design with the lang team in the form of a design meeting or RFC.
+We have a design for `min_generic_const_args` in mind but would like to validate it through implementation as const generics has a history of unforeseen issues showing up during implementation. Therefore we will pursue a prototype implementation in 2025. As a stretch goal, we will attempt to review the design with the lang team in the form of a design meeting or RFC.
 
 In the past 6 months preliminary refactors were made to allow actually implementing the core of the design, this took significantly longer than expected which highlights the importance of actually implementing the design to see if it works.
 

src/2025h1/rust-vision-doc.md

@@ -39,7 +39,7 @@ Writing the "status quo" stories helped us to compensate for the [curse of knowl
 [Async Vision Doc]: https://rust-lang.github.io/wg-async/vision.html
 [status quo]: https://rust-lang.github.io/wg-async/vision/submitted_stories.html
 [shiny future]: https://rust-lang.github.io/wg-async/vision/shiny_future/users_manual.html
-[cast of four characteres]: https://rust-lang.github.io/wg-async/vision/characters.html
+[cast of four characters]: https://rust-lang.github.io/wg-async/vision/characters.html
 
 #### Gathering stories from both individuals and groups
 
@@ -71,7 +71,7 @@ Here is the overall plan for 2025H1:
 |----------------------------------------------|-----|-----|-----|-----|-----|-----|-----|-----|
 | Form a team                                  | ███ | ███ |     |     |     |     |     |     |
 | Gather status quo stories                    |     |     | ███ | ███ | ░░░ |     |     |     |
-| Coallesce stores and personae                |     |     | ░░░ | ███ | ███ |     |     |     |
+| Coalesce stories and personae                |     |     | ░░░ | ███ | ███ |     |     |     |
 | Develop recommendations and goals            |     |     |     | ░░░ | ███ |     |     |     |
 | Review RFC Draft 1 at Rust All Hands         |     |     |     |     |     | ███ | ███ |     |
 | Publish a blog post with summarized feedback |     |     |     |     |     |     |     | ███ |
@@ -89,7 +89,7 @@ Approval of the RFC indicates general alignment with the framing and prioritizes
 
 ### The "shiny future" we are working towards
 
-Assuming this vision doc is succesful, we believe it should be refreshed on a regular basis. This would be a good completement to the Rust Project Goal system. Project Goals describe the next few steps. The Vision Doc helps to outline the destination.
+Assuming this vision doc is successful, we believe it should be refreshed on a regular basis. This would be a good completement to the Rust Project Goal system. Project Goals describe the next few steps. The Vision Doc helps to outline the destination.
 
 We also expect that the Vision Doc template may be useful in other more narrow contexts, such as a revised version of the Async Vision Doc,a vision doc for Rust in UI, machine learning, etc.
 

src/2025h1/spec-fls-integration.md

@@ -8,11 +8,11 @@
 
 ## Summary
 
-Ferrous Systems will be transfering the Ferrocene Language Specification (FLS) to the Rust Project, under the ownership of the Specification Team, or `t-spec`. In the first half of 2025, the Specification team will integrate the FLS, under an appropriate name, into both its design and development processes, and the project as a whole.
+Ferrous Systems will be transferring the Ferrocene Language Specification (FLS) to the Rust Project, under the ownership of the Specification Team, or `t-spec`. In the first half of 2025, the Specification team will integrate the FLS, under an appropriate name, into both its design and development processes, and the project as a whole.
 
 ## Motivation
 
-The Specification Team has been working for the past year on preparing a specification of Rust. Over this time, the Team has made and began executing several distinct plans to achieve this: creating a new document; modifying the reference; and most recently, agreeing with Ferrous Systems to take ownership of the FLS to support its specification delivery efforts. The current plan is to do the latter two processes in parrallel, and in order to do that effectively the Ferrocene Language Specification needs to be adopted and integrated into the project processes and tooling.
+The Specification Team has been working for the past year on preparing a specification of Rust. Over this time, the Team has made and began executing several distinct plans to achieve this: creating a new document; modifying the reference; and most recently, agreeing with Ferrous Systems to take ownership of the FLS to support its specification delivery efforts. The current plan is to do the latter two processes in parallel, and in order to do that effectively the Ferrocene Language Specification needs to be adopted and integrated into the project processes and tooling.
 
 ### The status quo
 
@@ -38,7 +38,7 @@ The goal is designed to move forward the Rust Specification, in a way that is sa
 The following [design axioms][da] apply:
 * Making Decisions Effectively, but Efficiently: When the goal asks the Team to make a decision, the Team should be prepared in advance with the necessary background, and come to consensus based on as much information as is possible, but at the same time, acting with efficiency and alacrity, not spending more time than is necessary on a decision. In particular, the team should not delay discussing a decision more than is necessary.
     * Elaborating on the last part, decisions the team are well aware of needing to make should not be deferred once all of the requesite information is available, unless a higher priority decision needs to supplant it.
-* Iterative changes are better: When it comes to making modifications, particularily to the FLS, slow and gradual ones should be preferred to sharp, major ones.
+* Iterative changes are better: When it comes to making modifications, particularly to the FLS, slow and gradual ones should be preferred to sharp, major ones.
 
 [da]: ../about/design_axioms.md
 

src/admin/mdbook_plugin.md

@@ -4,10 +4,10 @@ The mdbook is controlled by the `mdbook-goals` plugin in this repo.
 This plugin makes various edits to the source:
 
 * Linking usernames like <code>&#x40;foo</code> to their github page and replacing them with their display name.
-* Linking GH references lke rust-lang/rust#123.
+* Linking GH references like rust-lang/rust#123.
 * Collating goals, creating tables, etc.
 
-The plugin can also be used [from the commmand line](./commands.md).
+The plugin can also be used [from the command line](./commands.md).
 
 ## Expected book structure
 

src/admin/samples/cfp.md

@@ -7,7 +7,7 @@
 > * Search and replace `YYYYHN` with `2222H1` and delete this section.
 > * Look for other "TBD" sections, you'll want to replace those eventually.
 
-**As of today, we are officially accepting proposals for Rust Project Goals targeting YYYYHN (the (TBD) half of YYYY).** If you'd like to particiapte in the process, or just to follow along, please check out the [YYYYHN goal page][YYYYHN]. It includes listings of the goals currently under consideration , more details about the goals program, and instructions for how to submit a goal.
+**As of today, we are officially accepting proposals for Rust Project Goals targeting YYYYHN (the (TBD) half of YYYY).** If you'd like to participate in the process, or just to follow along, please check out the [YYYYHN goal page][YYYYHN]. It includes listings of the goals currently under consideration , more details about the goals program, and instructions for how to submit a goal.
 
 [YYYYHN]: https://rust-lang.github.io/rust-project-goals/YYYYHN/index.html