automate the launch of a new cfp with the cfp command

.ai/architecture.md

@@ -0,0 +1,11 @@
+This repository runs the Rust open source "project goals" program.
+
+It is structured as an mdbook combined with custom rust code to manage the contents of that mdbook and perform other chores.
+
+The mdbook sources can be found in `src` and in `book.toml`.
+
+The `src/admin` directory in particular contains instructions targeting the people who maintain and run the project goal program. It describes the processes for tasks like beginning a new goals program, authoring goal updates, and so forth.
+
+Many of the tasks in `src/admin` are automated via a utility called `cargo rpg`.
+
+The sources for `cargo rpg` as well as the plugin for the mdbook processor are found in crates located in the `crates` directory. The `crates/README.md` summarizes the role of each crate.

book.toml

@@ -7,6 +7,9 @@ title = "Rust Project Goals"
 
 [preprocessor.goals]
 command = "cargo run -p mdbook-goals --"
+ignore_users = [
+    "@triagebot",
+]
 
 [preprocessor.goals.links]
 "Help wanted" = "https://img.shields.io/badge/Help%20wanted-yellow"
@@ -23,10 +26,6 @@ command = "cargo run -p mdbook-goals --"
 [preprocessor.goals.users]
 "@Nadrieril" = "@Nadrieril"
 
-preprocessor.goals.ignore_users = [
-    "@triagebot",
-]
-
 
 [output.html]
 git-repository-url = "https://github.com/rust-lang/rust-project-goals"

crates/README.md

@@ -0,0 +1,8 @@
+The support crates for running the rust-project-goals program.
+
+The main crates of interest are:
+
+* `mdbook-goals`, which is an mdbook plugin that processes the project goal markdown files found in `../src` to populate indices and other content dynamically.
+* `rust-project-goals-cli`, which contains the main helper tool, invoked with `cargo rpg` (there is an alias defined in the `.cargo` directory).
+    * The `rust-project-goals-*` crates are dependencies of `rust-project-goals-cli` for other more specialized tasks.
+* The `rust-project-goals` crate is a library used by `mdbook-goals` and by the CLI tool to encapsulate common tasks like scanning for goal documents.

crates/rust-project-goals-cli/src/main.rs

@@ -6,6 +6,7 @@ use rust_project_goals_llm::UpdateArgs;
 use std::path::PathBuf;
 use walkdir::WalkDir;
 
+mod cfp;
 mod generate_json;
 mod rfc;
 mod team_repo;
@@ -29,6 +30,20 @@ enum Command {
 
     /// Print the RFC text to stdout
     RFC { path: PathBuf },
+
+    /// Set up a new Call For Proposals (CFP) period
+    CFP {
+        /// Timeframe for the new CFP period (e.g., 2025h1)
+        timeframe: String,
+
+        /// Force overwrite without asking for confirmation
+        #[arg(short = 'f', long = "force")]
+        force: bool,
+
+        /// Dry run - don't make any changes, just show what would be done
+        #[arg(short = 'n', long = "dry-run")]
+        dry_run: bool,
+    },
 
     /// Use `gh` CLI tool to create issues on the rust-lang/rust-project-goals repository
     Issues {
@@ -86,6 +101,10 @@ fn main() -> anyhow::Result<()> {
             rfc::generate_comment(&path)?;
         }
 
+        Command::CFP { timeframe, force, dry_run } => {
+            cfp::create_cfp(timeframe, *force, *dry_run)?;
+        }
+
         Command::Check {} => {
             check()?;
         }

src/2025h2/README.md

@@ -0,0 +1,103 @@
+# Rust project goals 2025h2
+
+
+## Summary
+
+*![Status: Accepting goal proposals](https://img.shields.io/badge/Status-Accepting%20goal%20proposals-yellow) We are in the process of assembling the goal slate.*
+
+This is a draft for the eventual RFC proposing the 2025h2 goals.
+
+## Motivation
+
+The 2025h2 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 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.
+
+Of the proposed goals, a small subset are selected by the roadmap owner as **flagship goals**. Flagship goals are chosen for their high impact (many Rust users will be impacted) and their shovel-ready nature (the org is well-aligned around a concrete plan). Flagship goals are the ones that will feature most prominently in our public messaging and which should be prioritized by Rust teams where needed.
+
+### Rust’s mission
+
+Our goals are selected to further Rust's mission of **empowering everyone to build reliable and efficient software**. Rust targets programs that prioritize
+
+* reliability and robustness;
+* performance, memory usage, and resource consumption; and
+* long-term maintenance and extensibility.
+
+We consider "any two out of the three" as the right heuristic for projects where Rust is a strong contender or possibly the best option.
+
+### Axioms for selecting goals
+
+We believe that...
+
+* **Rust must deliver on its promise of peak performance and high reliability.** Rust’s maximum advantage is in applications that require peak performance or low-level systems capabilities. We must continue to innovate and support those areas above all.
+* **Rust's goals require high productivity and ergonomics.** Being attentive to ergonomics broadens Rust impact by making it more appealing for projects that value reliability and maintenance but which don't have strict performance requirements.
+* **Slow and steady wins the race.** For this first round of goals, we want a small set that can be completed without undue stress. As the Rust open source org continues to grow, the set of goals can grow in size.
+
+## Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+### Flagship goals
+
+The flagship goals proposed for this roadmap are as follows:
+
+(TBD)
+
+#### Why these particular flagship goals?
+
+(TBD--typically one paragraph per goal)
+
+### Project goals
+
+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 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.
+
+<!-- GOALS -->
+
+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+The following table highlights the asks from each affected team.
+The "owner" in the column is the person expecting to do the design/implementation work that the team will be approving.
+
+<!-- TEAM ASKS -->
+
+### Definitions
+
+Definitions for terms used above:
+
+* *Author RFC* and *Implementation* means actually writing the code, document, whatever.
+* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback (no decision expected).
+* *RFC decisions* means reviewing an RFC and deciding whether to accept.
+* *Org decisions* means reaching a decision on an organizational or policy matter.
+* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review.
+* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize.
+* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated.
+* Other kinds of decisions:
+    * [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written.
+    * Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used to propose a 'larger than average' change and get feedback from the compiler team.
+    * Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html) describes a change to the standard library.
+
+[AGS]: ./Project-goal-slate.md
+[AMF]: ./a-mir-formality.md
+[Async]: ./async.md
+[ATPIT]: ./ATPIT.md
+[CS]: ./cargo-script.md
+[CT]: ./const-traits.md
+[ERC]: ./ergonomic-rc.md
+[MGCA]: ./min_generic_const_arguments.md
+[NBNLB]: ./Polonius.md
+[NGS]: ./next-solver.md
+[PET]: ./Patterns-of-empty-types.md
+[PGC]: ./pubgrub-in-cargo.md
+[RFL]: ./rfl_stable.md
+[SBS]: ./sandboxed-build-script.md
+[YKR]: ./yank-crates-with-a-reason.md
+[SC]: ./Rust-for-SciComp.md
+[OC]: ./optimize-clippy.md
+
+<!-- Github usernames -->

src/2025h2/goals.md

@@ -0,0 +1,22 @@
+# Goals
+
+
+This page lists the <!-- #GOALS --> project goals **proposed** for 2025h2.
+
+> Just because a goal is listed on this list does not mean the goal has been accepted.
+> The owner of the goal process makes the final decisions on which goals to include
+> and prepares an RFC to ask approval from the teams.
+
+## Flagship goals
+
+Flagship goals represent the goals expected to have the broadest overall impact. 
+
+<!-- FLAGSHIP GOALS -->
+
+## Other goals
+
+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 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 -->

src/2025h2/not_accepted.md

@@ -0,0 +1,6 @@
+# Not accepted
+
+
+This section contains goals that were proposed but ultimately not accepted, either for want of resources or consensus. In many cases, narrower versions of these goals were proposed instead.
+
+<!-- GOALS NOT ACCEPTED -->

src/README.md

@@ -22,9 +22,10 @@ The 2025H1 goal period runs from Jan 1 to Jun 30. We have identified three flags
 
 [The full list of 2025H1 goals is available here.](./2025h1/goals.md) We author monthly blog posts about our overall status, but you can also follow the tracking issue for a [particular goal](./2025h1/goals.md) to get updates specific to that goal.
 
-## Next goal period (2025h2)
 
-Discussion about goals for the next goal period will begin in May.
+## Next goal period (2025H2)
+
+The next goal period will be 2025H2, running from July 1 to December 30. We are currently in the process of assembling goals. [Click here](./2025h2/goals.md) to see the current list. If you'd like to propose a goal, [instructions can be found here](./how_to/propose_a_goal.md).
 
 ## About the process
 

src/SUMMARY.md

@@ -10,7 +10,9 @@
 
 # ⏳ 2025H2 goal process
 
-- [Not yet started]()
+- [Overview](./2025h2/README.md)
+- [Proposed goals](./2025h2/goals.md)
+- [Goals not accepted](./2025h2/not_accepted.md)
 
 # 📖 Learn about
 

src/admin/cfp.md

@@ -5,7 +5,50 @@ Each goal milestone corresponds to six months, designated in the format YYYYhN,
 * For an H1 season, start around mid October of the year before.
 * For an H2 season, start around mid April of the year before.
 
-This is the checklist of steps to starting accepting goal proposals:
+## Using the automated setup command
+
+The easiest way to set up a new Call For Proposals (CFP) period is to use the `cargo rpg cfp` command. This command automates the process of creating the necessary directory structure, copying template files, and updating both the SUMMARY.md and README.md files.
+
+```bash
+# Basic usage
+cargo rpg cfp 2025h2
+
+# Force overwrite without asking for confirmation
+cargo rpg cfp 2025h2 --force
+
+# Dry run - don't make any changes, just show what would be done
+cargo rpg cfp 2025h2 --dry-run
+```
+
+The command will:
+1. Create a new directory for the specified timeframe (e.g., `src/2025h2/`)
+2. Copy and process template files from `src/admin/samples/` to the new directory
+3. Update the `SUMMARY.md` file to include the new timeframe section
+4. Update the main `README.md` with information about the new timeframe
+
+## Manual steps required
+
+After running the `cargo rpg cfp` command, there are still important manual steps that need to be completed:
+
+### 1. Prepare and publish a blog post
+
+You need to prepare a Call For Proposals blog post on the [Inside Rust] blog:
+* Use [this sample](./samples/cfp.md) as a starting point
+* Copy the sample to the `blog.rust-lang.org` repository as a new post
+* Replace placeholders like `YYYYHN` with the actual timeframe (e.g., `2025H2`)
+* We use Inside Rust and not the Main blog because the target audience is would-be Rust contributors and maintainers
+
+### 2. Email the mailing list
+
+Send an email to the `[email protected]` mailing list to announce the Call For Proposals:
+* Include a link to the blog post
+* Summarize the key dates and process
+* Encourage team participation and feedback
+* This step is crucial for ensuring all Rust team members are aware of the upcoming goal period
+
+## Manual setup checklist
+
+If you prefer to set up the CFP manually, or need to customize the process beyond what the automated command provides, here's a checklist of steps:
 
 * [ ] Prepare a Call For Proposals blog post on the [Inside Rust] blog based on [this sample](./samples/cfp.md).
     * We use Inside Rust and not the Main blog because the target audience is would-be Rust contributors and maintainers.

src/admin/commands.md

@@ -3,3 +3,29 @@
 The `cargo rpg` command is a CLI for manipulating and checking project goals. This section provides a reference describing (some of) the ability commands. You can also try `cargo rpg --help` to get a summary.
 
 Note that this relies on the [`gh` client](https://github.com/cli/cli), which needs to be installed and configured with a token (for example using `gh auth login`).
+
+## Available Commands
+
+### `cargo rpg cfp`
+
+Sets up a new Call For Proposals (CFP) period. This command automates the process of creating the necessary directory structure, copying template files, and updating both the SUMMARY.md and README.md files.
+
+```bash
+# Basic usage
+cargo rpg cfp <timeframe>
+
+# Options
+cargo rpg cfp <timeframe> --force    # Force overwrite without asking for confirmation
+cargo rpg cfp <timeframe> --dry-run  # Don't make any changes, just show what would be done
+```
+
+Example:
+```bash
+cargo rpg cfp 2025h2
+```
+
+Note that after running this command, you'll still need to manually:
+1. Prepare and publish a blog post on the Inside Rust blog
+2. Send an email to the `[email protected]` mailing list
+
+For more details, see the [Call for proposals](./cfp.md) documentation.

src/admin/samples/rfc.md

@@ -1,4 +1,4 @@
-# Sample RFC
+# Rust project goals YYYYHN
 
 > **NOTE:** This is a sample RFC you can use as a starting point.
 > To begin a new goal season (e.g., 2222H1), do the following: