From ed0ec0e56e92522d66bb2b7382f2d14158c130f4 Mon Sep 17 00:00:00 2001 From: James Thomson Date: Wed, 29 Apr 2026 22:14:48 +0100 Subject: [PATCH] fix various typos --- src/archive/fott.md | 2 +- src/compiler/operations.md | 2 +- .../ecosystem-integration-tests.md | 2 +- src/governance/project-groups.md | 4 ++-- src/how-to-start-contributing.md | 2 +- src/triagebot/issue-links.md | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/archive/fott.md b/src/archive/fott.md index 044191f5..47730ffe 100644 --- a/src/archive/fott.md +++ b/src/archive/fott.md @@ -238,7 +238,7 @@ reviewer. Thanks, Kevin, for your contributions! Gabor's major contributions to Rust have been in the area of language design. In the last year he has produced a number of very high quality RFCs, and though -many of them of not yet been accepted, his ideas are often thought-provoking and +many of them have not yet been accepted, his ideas are often thought-provoking and have had a strong influence on the direction of the language. His [trait based exception handling RFC][tbeh] was particularly innovative, as well that [for future-proofing checked arithmetic][checked]. Gabor is an exceedingly clever diff --git a/src/compiler/operations.md b/src/compiler/operations.md index 3afd194c..bd2b57af 100644 --- a/src/compiler/operations.md +++ b/src/compiler/operations.md @@ -4,7 +4,7 @@ Here is a list of recurring tasks. Ideally run through this list every week. If there are blockers or doubts, after having acquired the right context, don't hesitate to ping people around. Contributors are the best resource of the project (and we want to be mindful of their time) and are always helpful. -You can trigger a discussion about a specific topic, issue or pull request by opening a new topic on Zulip in [#t-compiler][t-compiler] or, if it needs consensus and more focus from the team, it can can be labeled `I-compiler-nominated` and will be discussed in a meeting (see section [Meetings][meetings]). +You can trigger a discussion about a specific topic, issue or pull request by opening a new topic on Zulip in [#t-compiler][t-compiler] or, if it needs consensus and more focus from the team, it can be labeled `I-compiler-nominated` and will be discussed in a meeting (see section [Meetings][meetings]). [meetings]: #meetings [t-compiler]: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler diff --git a/src/compiler/proposals-and-stabilization/ecosystem-integration-tests.md b/src/compiler/proposals-and-stabilization/ecosystem-integration-tests.md index 01e7b565..c7b06578 100644 --- a/src/compiler/proposals-and-stabilization/ecosystem-integration-tests.md +++ b/src/compiler/proposals-and-stabilization/ecosystem-integration-tests.md @@ -62,7 +62,7 @@ to provide are indicated by italicized sentences whose content should be replace NOTE: It is not the intention of this policy to make it frustrating annoying to add an ecosystem test job/component. We simply wish to gather the necessary background information upfront (especially working together to figure out a viable *Failure Protocol*) to minimize potential -frustrations from other [rust-lang/rust] contributors if and when the the test job/component do +frustrations from other [rust-lang/rust] contributors if and when the test job/component does fail, potentially blocking PR / Full Merge CI in completely unrelated PRs. --- diff --git a/src/governance/project-groups.md b/src/governance/project-groups.md index f2458169..25117592 100644 --- a/src/governance/project-groups.md +++ b/src/governance/project-groups.md @@ -27,7 +27,7 @@ Part of building a community is removing some of the institutional memory that d Previously a lot of the discussion and iteration for large features would happen in the initial RFC thread. This leads to a lot of discussion in the top of the thread and that often becomes completely irrelevant to the current iteration. -This process has also been unsuitable to describe features that can take multiple years to develop and will become multiple RFCs over the course of its design process. Some examples of of this are the "`impl Trait`" and "macros 2.0" features, where the goals has shifted a lot from the initial RFCs, and it can be hard to know their current status. +This process has also been unsuitable to describe features that can take multiple years to develop and will become multiple RFCs over the course of its design process. Some examples of this are the "`impl Trait`" and "macros 2.0" features, where the goals has shifted a lot from the initial RFCs, and it can be hard to know their current status. [ffi unwind]: https://github.com/rust-lang/project-ffi-unwind [inline asm]: https://github.com/rust-lang/project-inline-asm @@ -101,7 +101,7 @@ Once that has been resolved the group should write an announcement of their arch ### Retrospective -While this RFC attempts to address some of the current organisational problems within the organisation, the author doesn't believe will be a panacea to those problems or that we won't encounter new problems in the future. As part of that, the RFC introduce having retrospectives with the groups once significant time has past or the group has finished its project. +While this RFC attempts to address some of the current organisational problems within the organisation, the author doesn't believe will be a panacea to those problems or that we won't encounter new problems in the future. As part of that, the RFC introduce having retrospectives with the groups once significant time has passed or the group has finished its project. This would involve a discussion between the members of the group, and ideally their parent team and the Governance working group. The retrospective should produce a public blog post on the Inside Rust blog, however any feedback a member has that they would want to keep private would be omitted. diff --git a/src/how-to-start-contributing.md b/src/how-to-start-contributing.md index 83a21ccb..59912026 100644 --- a/src/how-to-start-contributing.md +++ b/src/how-to-start-contributing.md @@ -25,7 +25,7 @@ official website for more resources. **Please ask questions!** A lot of people report feeling that they are "wasting expert time", but we do not feel that way. Contributors are important to us. -If you want to contribute substancial changes, we suggest first contacting the team relevant to +If you want to contribute substantial changes, we suggest first contacting the team relevant to these changes. Each teams has their own preferred workflow, please follow the recommended path in order to have a prior discussion and team buy-in: - Compiler team: a Major Change Proposal (MCP) or a Request For Comment (RFC) (read more [here][mcp-or-rfc-compiler]) diff --git a/src/triagebot/issue-links.md b/src/triagebot/issue-links.md index 8c73398c..e2a5fcd3 100644 --- a/src/triagebot/issue-links.md +++ b/src/triagebot/issue-links.md @@ -9,7 +9,7 @@ This is useful when updating subtrees into the upstream repository as it avoids ## Issue Links in Commits -GitHub also permits having having issue links in commits which are then referenced in the issue. While useful, they often more than anything else spam the referenced issue. This handler puts a warning against them. +GitHub also permits having issue links in commits which are then referenced in the issue. While useful, they often more than anything else spam the referenced issue. This handler puts a warning against them. ## Configuration