diff --git a/src/2025h1/README.md b/src/2025h1/README.md index d935fc4..2f6496b 100644 --- a/src/2025h1/README.md +++ b/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 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 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. diff --git a/src/2025h1/all-hands.md b/src/2025h1/all-hands.md index 6282898..236fe5e 100644 --- a/src/2025h1/all-hands.md +++ b/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, diff --git a/src/2025h1/cargo-plumbing.md b/src/2025h1/cargo-plumbing.md index 081fb87..efde77f 100644 --- a/src/2025h1/cargo-plumbing.md +++ b/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 diff --git a/src/2025h1/min_generic_const_arguments.md b/src/2025h1/min_generic_const_arguments.md index e73ef10..844847c 100644 --- a/src/2025h1/min_generic_const_arguments.md +++ b/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. diff --git a/src/2025h1/open-namespaces.md b/src/2025h1/open-namespaces.md index 5a87f33..1d4fcd0 100644 --- a/src/2025h1/open-namespaces.md +++ b/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 diff --git a/src/2025h1/rust-vision-doc.md b/src/2025h1/rust-vision-doc.md index 17fe493..139a164 100644 --- a/src/2025h1/rust-vision-doc.md +++ b/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. diff --git a/src/2025h1/spec-fls-integration.md b/src/2025h1/spec-fls-integration.md index 67e69dd..daac016 100644 --- a/src/2025h1/spec-fls-integration.md +++ b/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 diff --git a/src/README.md b/src/README.md index 53afc1c..757d651 100644 --- a/src/README.md +++ b/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) diff --git a/src/TEMPLATE.md b/src/TEMPLATE.md index 554be53..b4ae9c8 100644 --- a/src/TEMPLATE.md +++ b/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 diff --git a/src/about/poc.md b/src/about/poc.md index ee985f1..587c3c7 100644 --- a/src/about/poc.md +++ b/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. diff --git a/src/admin/mdbook_plugin.md b/src/admin/mdbook_plugin.md index 4865a00..ad8e961 100644 --- a/src/admin/mdbook_plugin.md +++ b/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 @foo 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 diff --git a/src/admin/samples/cfp.md b/src/admin/samples/cfp.md index 3dda016..0509fa6 100644 --- a/src/admin/samples/cfp.md +++ b/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. diff --git a/src/admin/samples/goals.md b/src/admin/samples/goals.md index bf5c534..b6d454e 100644 --- a/src/admin/samples/goals.md +++ b/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. diff --git a/src/admin/samples/rfc.md b/src/admin/samples/rfc.md index d2c6d4a..676c5b9 100644 --- a/src/admin/samples/rfc.md +++ b/src/admin/samples/rfc.md @@ -16,11 +16,11 @@ This is a draft for the eventual RFC proposing the YYYYHN goals. ## Motivation -The YYYYHN goal slate consists of project goals, of which we have selected (TBD) as **flagship goals**. Flagship goals represent the goals expected to have the broadest overall impact. +The YYYYHN goal slate consists of 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 point of contact 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 point of contact 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. @@ -59,9 +59,9 @@ The flagship goals proposed for this roadmap are as follows: ### Project goals -The full slate of project goals are as follows. These goals all have identified owners who will drive the work forward as well as a viable work plan. The goals include asks from the listed Rust teams, which are cataloged in the [reference-level explanation](#reference-level-explanation) section below. +The full slate of project goals are as follows. These goals all have identified points of contact who will drive the work forward as well as a viable work plan. The goals include asks from the listed Rust teams, which are cataloged in the [reference-level explanation](#reference-level-explanation) section below. -**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. diff --git a/src/admin/setup.md b/src/admin/setup.md index 8d74ca4..e874d5b 100644 --- a/src/admin/setup.md +++ b/src/admin/setup.md @@ -13,7 +13,7 @@ The rust-project-goals repository is set up as follows * tagged with `C-tracking-issue` * and added to the appropriate milestone * triagebot modifications to link Zulip and the repo tracking issues - * the command `@triagebot ping-goals N D` will ping all active goal owners to ask them to add updates + * the command `@triagebot ping-goals N D` will ping all active goal points of contact to ask them to add updates * *N* is a threshold number of days; if people have posted an update within the last N days, we won't bother them. Usually I do this as the current date + 7, so that people who posted during the current month or the last week of the previous month don't get any pings. * *D* is a word like `Sep-22` that indicates the day * the bot monitors for comments on github and forwards them to Zulip diff --git a/src/admin/team.md b/src/admin/team.md index 5b33b04..139f93a 100644 --- a/src/admin/team.md +++ b/src/admin/team.md @@ -1,6 +1,6 @@ # Goals team -The Rust goals program is administered by the Goals team. +The Rust goals program is administered by the Goals team. This document serves as the team charter. ## Mission @@ -21,7 +21,7 @@ Team members perform some subset of the following roles: * During the year: * Authoring round-up blog posts highlighting progress * Updating and maintaining the web-site - * Checking in with the owners of goals that are not reporting progress to see if they need help + * Checking in with the goal points of contact that are not reporting progress to see if they need help ## Role of the lead diff --git a/src/how_to/report_status.md b/src/how_to/report_status.md index b3aedda..e932b46 100644 --- a/src/how_to/report_status.md +++ b/src/how_to/report_status.md @@ -1,6 +1,6 @@ # Report status -Every accepted project goal has an associated tracking issue. These are created [automatically by the project-goals admin tool](../admin/issues.md). Your job as a project goal owner is to provide regular status updates in the form of a comment indicating how things are going. These will be collected into regular blog posts on the Rust blog as well as being promoted in other channels. +Every accepted project goal has an associated tracking issue. These are created [automatically by the project-goals admin tool](../admin/issues.md). Your job as a project goal point of contact is to provide regular status updates in the form of a comment indicating how things are going. These will be collected into regular blog posts on the Rust blog as well as being promoted in other channels. ## Updating the progress bar