Rust project goals make cross-team commitments visible

An accepted design does not automatically supply an implementer, reviewer time, or agreement between all the teams needed to deliver it. Rust's August 12 project-goals announcement addresses that coordination problem. The project has selected 26 goals for the second half of 2024, with named owners and explicit requests for support from the relevant teams.

The process is experimental. Its first slate includes preparation for the next edition, improvements to async Rust, and work on the largest blockers to building the Linux kernel with stable Rust. Those are commitments to pursue defined work. They are not a claim that each underlying problem is already solved.

I am impressed by Rust's semantics and its suitability for low-level systems work. That technical appeal also makes coordination important. A feature can involve language rules, compiler implementation, and library conventions at once. Public ownership helps explain where progress depends on work outside the feature's immediate implementation.

A goal records the next step toward a larger result

The RFC 3614 discussion explains the program as an experiment toward an ongoing roadmap. Its proposal calls for an initial slate and progress tracking, with lessons informing a more durable process. The Leadership Council accepted that experiment in April.

One review question concerns how a goal relates to time. A long-term ambition can span years, while a planning cycle needs a smaller step that can be evaluated. The author's response describes goals as particular steps within a period shorter than six months, often contributing to a larger objective.

That distinction is useful for technical work with uncertain outcomes. An experiment can establish whether an approach is viable without delivering every feature it might eventually enable. A stabilization effort can identify the remaining blockers without promising that every blocker will disappear within the same cycle.

The August announcement follows that logic by describing both flagship efforts and more specific goals. It gives owners for work such as single-file scripts, borrow-checker improvements, and merged documentation tests. Naming an owner makes progress and impediments attributable to a work item instead of leaving readers to infer responsibility from an issue's activity.

Reviewer capacity belongs in the commitment

The RFC discussion also asks what happens if an owner expects to work many hours each week while the supporting team expects to provide very little review time. Both parties could be acting reasonably and still become frustrated. A goal needs to make those expectations explicit before the mismatch dominates the work.

That is an engineering constraint. A contribution requiring compiler review cannot be completed by implementation effort alone. The supporting team must understand what judgment or integration work it is agreeing to supply. The goal's owner likewise needs to know what assistance is actually available.

The August process collected goals as pull requests, discussed them with teams, and sometimes revised or split them. It then assembled the slate into RFC 3672, including each team's requested support. The announcement says the teams receiving those requests approved the RFC.

This adds information beyond a list of desirable features. It associates an intended outcome with an owner and a support agreement. Someone deciding whether to contribute can see a project that relevant maintainers consider useful and understand that it still has concrete coordination requirements.

The flagship work has different technical dependencies

Edition preparation concerns language ergonomics and compatibility boundaries. The announcement lists changes to capture behavior, reserving a keyword for possible generators, and fallback involving the never type. Its goal is to complete preparation work. These descriptions do not imply that every future language capability mentioned by an edition change is being delivered at once.

Async Rust has another dependency structure. The announcement identifies async closures and Send bounds as building blocks in a multi-year effort to improve the experience relative to synchronous Rust. A building block can unblock later work without making every async abstraction immediately as convenient as its synchronous counterpart.

The Linux goal concerns unstable features blocking stable-toolchain support for kernel development. That is a specific obstacle between experimental integration and a more sustainable dependency on stable Rust. The goal is to close the largest gaps, rather than declare that all low-level systems requirements have already become stable interfaces.

These differences explain why a shared process should record deliverables without forcing every effort into the same technical milestone. Language preparation, feature stabilization, and ecosystem integration can require different evidence. The common structure supplies ownership and support, while each goal describes its own next step.

Public tracking includes the possibility of incomplete work

The announcement points readers to tracking issues in the 2024h2 milestone, assigned to the relevant owners. It also commits to progress summaries. That provides a way to observe work across teams without treating every implementation issue as a complete account of the project-level objective.

The organizers explicitly do not expect every goal to finish. Many goals depend on volunteers, and a stalled effort may need a new owner or reconsideration during another planning round. An accepted goal is therefore evidence of intended direction and support, not a warranty of completion.

That is consistent with the RFC's experimental framing. Tracking unfinished work can reveal an unrealistic scope or a missing dependency. It can also show that an apparently small change requires more review than expected. The process is useful if it exposes those facts in time to adjust commitments.

I find that treatment more credible than a roadmap that silently drops incomplete entries. A systems language should be able to explain what it intends to attempt and what that attempt still depends on. The same public record can help distinguish an abandoned approach from work merely waiting for an owner.

Endorsement can help contributors secure time

The announcement also describes a funding purpose. An approved goal gives people outside the existing maintainer group a way to obtain feedback before investing heavily. It can help a contributor ask an employer for time or explain to a funder why a proposed effort fits the project's direction.

That does not replace technical review. It reduces uncertainty about whether the effort addresses a recognized need and whether teams have agreed to participate. The first slate makes that recognition concrete through named goals, ownership, and support requests, while keeping implementation and completion visible as work still to be done.