rm "goal owners"

lqd · lqd · commit 42a4b02826be · 2024-12-20T16:09:35.000Z
diff --git 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
@@ -76,7 +76,7 @@ Here is the overall plan for 2025H1:
 | 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:
 
diff --git 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
@@ -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/admin/samples/cfp.md b/src/admin/samples/cfp.md
@@ -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/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 `&#64;triagebot ping-goals N D` will ping all active goal owners to ask them to add updates
+    * the command `&#64;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/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
 
