Merge pull request #209 from lqd/rm-owners

some more "owner" -> "point of contact" changes

src/2025h1/README.md

@@ -6,11 +6,11 @@ This is a draft for the eventual RFC proposing the 2025H1 goals.
 
 ## Motivation
 
-The 2025H1 goal slate consists of <!-- #GOALS --> project goals, of which we have selected (TBD) as **flagship goals**. Flagship goals represent the goals expected to have the broadest overall impact. 
+The 2025H1 goal slate consists of <!-- #GOALS --> project goals, of which we have selected (TBD) as **flagship goals**. Flagship goals represent the goals expected to have the broadest overall impact.
 
 ### How the goal process works
 
-**Project goals** are proposed bottom-up by an **owner**, somebody who is willing to commit resources (time, money, leadership) to seeing the work get done. The owner identifies the problem they want to address and sketches the solution of how they want to do so. They also identify the support they will need from the Rust teams (typically things like review bandwidth or feedback on RFCs). Teams then read the goals and provide feedback. If the goal is approved, teams are committing to support the owner in their work. 
+**Project goals** are proposed bottom-up by a **point of contact**, somebody who is willing to commit resources (time, money, leadership) to seeing the work get done. The owner identifies the problem they want to address and sketches the solution of how they want to do so. They also identify the support they will need from the Rust teams (typically things like review bandwidth or feedback on RFCs). Teams then read the goals and provide feedback. If the goal is approved, teams are committing to support the owner in their work.
 
 Project goals can vary in scope from an internal refactoring that affects only one team to a larger cross-cutting initiative. No matter its scope, accepting a goal should never be interpreted as a promise that the team will make any future decision (e.g., accepting an RFC that has yet to be written). Rather, it is a promise that the team are aligned on the contents of the goal thus far (including the design axioms and other notes) and will prioritize giving feedback and support as needed.
 

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/open-namespaces.md

@@ -37,7 +37,7 @@ Implement at least Cargo and compiler support for this to be experimented with a
 |-------------------------------------|-------------------------------|-------|
 | Discussion and moral support        | ![Team][] [cargo], [compiler] |       |
 | Compiler implementation             | ![Help wanted][]              |       |
-| Work through lingering cargo issues | Goal owner, @epage            |       |
+| Work through lingering cargo issues | Goal point of contact, @epage |       |
 
 ### Definitions
 

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,12 +71,12 @@ 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 |     |     |     |     |     |     |     | ███ |
 
-The plan actually begins *now*, in the goal construction phase. One of the tasks to be done is building up a **small support team** of researchers who will help with doing the interviews and authoring status quo stories and other parts of the document. As goal owner, nikomatsakis will select initial members. With the Async Vision Doc, our experience was that most Rust users are eager to share their experiences, but that authoring and upleveling that into a status quo story is challenging. It's better to centralize that authorship into a small group of motivated people.
+The plan actually begins *now*, in the goal construction phase. One of the tasks to be done is building up a **small support team** of researchers who will help with doing the interviews and authoring status quo stories and other parts of the document. As goal point of contact, nikomatsakis will select initial members. With the Async Vision Doc, our experience was that most Rust users are eager to share their experiences, but that authoring and upleveling that into a status quo story is challenging. It's better to centralize that authorship into a small group of motivated people.
 
 The plan to finalize the document is as follows:
 
@@ -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/README.md

@@ -21,4 +21,4 @@ Want to learn more? Check out some of the following:
 * [RFC #3614, which describes the overall goals and plan](https://github.com/rust-lang/rfcs/blob/master/text/3614-project-goals.md)
 * The currently [proposed goals for 2024H2](./2024h2/slate.md)
 * [How to propose a goal of your own](./how_to/propose_a_goal.md)
-* [What it means to be a goal owner](./about/owners.md)
+* [What it means to be a goal point of contact](./about/owners.md)

src/TEMPLATE.md

@@ -64,17 +64,17 @@
 
 > *If you have a complex goal, you can include subsections for different parts of it, each with their own table. Must goals do not need this and can make do with a single table. The table in this section also lists the full range of "asks" for a typical language feature; feel free to copy some subset of them into your main table if you are primarily proposing a single feature (note that most features don't need all the entries below).*
 
-| Task                        | Owner(s) or team(s)     | Notes                                                         |
-|-----------------------------|-------------------------|---------------------------------------------------------------|
-| Lang-team experiment        | ![Team][] [lang]        | allows coding pre-RFC; only for trusted contributors          |
-| Author RFC                  | *Goal owner, typically* |                                                               |
-| Implementation              | *Goal owner, typically* |                                                               |
-| Standard reviews            | ![Team][] [compiler]    |                                                               |
-| Design meeting              | ![Team][] [lang]        |                                                               |
-| RFC decision                | ![Team][] [lang]        |                                                               |
-| Secondary RFC review        | ![Team][] [lang]        | most features don't need this                                 |
-| Author stabilization report | *Goal owner, typically* |                                                               |
-| Stabilization decision      | ![Team][] [lang]        | it's rare to author rfc, implement, AND stabilize in 6 months |
+| Task                        | Owner(s) or team(s)                | Notes                                                         |
+|-----------------------------|------------------------------------|---------------------------------------------------------------|
+| Lang-team experiment        | ![Team][] [lang]                   | allows coding pre-RFC; only for trusted contributors          |
+| Author RFC                  | *Goal point of contact, typically* |                                                               |
+| Implementation              | *Goal point of contact, typically* |                                                               |
+| Standard reviews            | ![Team][] [compiler]               |                                                               |
+| Design meeting              | ![Team][] [lang]                   |                                                               |
+| RFC decision                | ![Team][] [lang]                   |                                                               |
+| Secondary RFC review        | ![Team][] [lang]                   | most features don't need this                                 |
+| Author stabilization report | *Goal point of contact, typically* |                                                               |
+| Stabilization decision      | ![Team][] [lang]                   | it's rare to author rfc, implement, AND stabilize in 6 months |
 
 ### Definitions
 

src/about/poc.md

@@ -1,6 +1,6 @@
 # Goal point of contacts
 
-Every goal has a single **point of contact**. This is the person responsible for authoring updates and generally tracking the status of the goal. They will get regular pings to provide updeates.
+Every goal has a single **point of contact**. This is the person responsible for authoring updates and generally tracking the status of the goal. They will get regular pings to provide updates.
 
 We require a single point of contact to avoid confusion. But of course it is possible for that person to delegate the actual authoring of updates to others.
 

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
 
@@ -16,7 +16,7 @@
 Every six months, the Rust project commits to a set of goals for the upcoming half-year. The process involves:
 
 * the owner of the goal program (currently me) posts a call for proposals (this post);
-* would-be goal owners [open PRs][] against the [rust-project-goals] repository;
+* would-be goal points of contact [open PRs][] against the [rust-project-goals] repository;
 * the goal-program owner gathers feedback on these goals and chooses some of them to be included in the RFC proposing the final slate of goals.
 
 To get an idea what the final slate of goals looks like, check out the RFC from the previous round of goals, [RFC (TBD)][]. The RFC describes a set of goals, designates a few of them as flagship goals, and summarizes the work expected from each team. The RFC is approved by (at least) the leads of each team, effectively committing their team to prove the support that is described.

src/admin/samples/goals.md

@@ -20,6 +20,6 @@ Flagship goals represent the goals expected to have the broadest overall impact.
 
 These are the other proposed goals. 
 
-**Invited goals.** Some goals of the goals below are "invited goals", meaning that for that goal to happen we need someone to step up and serve as an owner. To find the invited goals, look for the ![Help wanted][] badge in the table below. Invited goals have reserved capacity for teams and a mentor, so if you are someone looking to help Rust progress, they are a great way to get involved.
+**Invited goals.** Some goals of the goals below are "invited goals", meaning that for that goal to happen we need someone to step up and serve as a point of contact. To find the invited goals, look for the ![Help wanted][] badge in the table below. Invited goals have reserved capacity for teams and a mentor, so if you are someone looking to help Rust progress, they are a great way to get involved.
 
 <!-- OTHER GOALS -->