我们很高兴地宣布一项名为 Rust 项目目标的实验性路线图制定工作的开始。正如 RFC 3614 中所述，计划为 2024 年下半年（2024H2）制定一系列项目目标。我们需要你的帮助！我们目前正在征集项目目标的想法，特别是那些有积极主动的负责人，他们有时间和资源来推动目标完成的想法。 如果您想提出目标，请在此处阅读有关该流程的更多信息！

目标并非一切，但它们是我们的优先事项

重要的是要强调，目标并非我们要做的一切的详尽清单。相反，它们是“大石头”，是我们最想关注和完成的最高优先级事项。

目标代表双重承诺

要被接受，一个目标需要一个负责人，即已同意完成将目标推进到完成所需工作的个人（或一小组个人）。然后，目标本身必须被一个或多个 Rust 团队接受，他们负责通过审查、反馈和及时决策来支持该负责人。

最终，我们希望项目团队提供可用的资源“菜单”，例如审阅带宽或设计/审阅会议时段。

项目目标允许负责人提前获得批准，表明相关的 Rust 团队足够关心该问题，愿意投入资源（例如会议时间和审阅带宽），这反过来又允许负责人投入资源（例如设计和开发时间）来解决该问题。

目标描述问题，而不是解决方案

目标侧重于我们计划解决的问题，而不是我们将用来解决它的具体解决方案。当团队接受一个目标时，他们表示该问题很重要，并且他们愿意投入工作来帮助负责人解决它。有时，负责人会对他们希望如何进行有一个非常清晰的想法，但通常他们不会，这没关系。

项目目标的解决方案草案可能包括实验，以确定解决方案的正确路径，并且人们想到的任何解决方案都可能随着目标的进展而完全改变。

负责人塑造提案，团队接受它

成为负责人是一个关键角色，也是我们之前在 Rust 中没有正式认可的角色。

成为负责人是一种承诺，但也是一种特权。负责人应作为该领域的总体专家。他们将与利益相关者互动，并接受和协调有关设计的意见。

作为对目标投入精力的交换，负责人被委托设计和提出解决方案。最终，Rust 项目团队将审查这些提出的解决方案并批准或拒绝它们，但期望团队提供反馈或附加要求，而不是自己接管设计。

目标规模

很难做出预测，尤其是关于未来的预测。

项目目标通常会描述实现目标后，未来 Rust 的美好前景。然而，众所周知，人类不擅长计划和估算，此外，资源承诺可能有时间限制，可能需要定期重新评估。

因此，项目目标应主要关注可以在年内完成的中期目标，以及在该时间范围内实现的现实里程碑。一些项目目标可能会在此时间范围内完全完成。其他项目目标可能会制定增量里程碑（例如发布 RFC），甚至只是确定可行性的实验。

没有负责人的目标

为了让团队接受一个目标并为此投入资源，它需要一个负责人。但是，在某些情况下，项目团队意识到他们希望解决的长期存在的问题，但他们没有确定具体的负责人来致力于解决这些问题。

作为一项实验，我们还将列出一些临时接受的 “没有负责人的目标”，这些目标团队已经初步审查过，并且表示如果有人站出来担任负责人，他们愿意为此投入资源。我们这样做既是为了提供一些项目目标的示例，也是为了邀请解决这些长期存在的问题。如果进展顺利，我们可能会制定更清晰的流程来预先批准这种需要负责人的目标。

如果您想在没有负责人的情况下起草类似目标，请与我们和潜在的项目团队联系。

相反，如果您想成为这些需要负责人的目标的负责人，请与目标上列出的团队中的某人联系。

目标选择过程

一般来说，只要团队有资源可以投入，他们可以随时接受新的项目目标。但是，我们也希望利用项目目标来形成路线图。此外，我们希望让团队尽可能容易地评估他们承诺的资源以及所有这些承诺是否兼容。

因此，对于这个首次实验，我们的主要目标是为 2024 年下半年（2024H2）选择一组目标。将来，我们将尝试找到在随时接受新目标和定期制定路线图和工作之间取得适当平衡。

开始

如果您想提出目标，请查看有关如何提出目标的文档。

如果您想成为需要负责人的目标的负责人，请与我们联系。

如果您想在某个地方讨论项目目标，请加入我们在 Zulip 上的讨论。