我们的 Rust 项目是一个庞大且多元化的项目。其活动主要由团队协调，为社区提供空间，让他们找到并贡献自己关心的事情。我们正在试验在 Libs 团队和编译器团队之间重新组织标准库活动。未来，Libs 团队将只拥有标准库的公共 API，而编译器团队将拥有其实现。这种职责分离的目标是更好地适应两个团队的兴趣，以更好地支持标准库的需求。这很像 Lang 团队和编译器团队之间的现有关系，其中 Lang 团队拥有 Rust 语言设计，而编译器团队拥有实现它的代码。我们将在今年晚些时候重新评估试验进展，并决定是否将这一改变永久化。

Libs 团队传统上选择喜欢设计 API 的成员。他们花费大量精力支持更广泛的 Rust 生态系统中的库，并努力将惯用法整合到标准 API 中。这为标准库本身的开发留下的空间很小，而标准库本身的开发需要持续和专注的关注。

作为一个代码库，标准库却具有矛盾的特殊性。它拥有对编译器内部的特权访问权限，算法中融入了深厚的领域知识（例如，你是否曾想过如何高效地将浮点数格式化为文本？），平台特定的集成，以及许多棘手的 unsafe 代码。

编译器团队习惯于持续和专注地关注大型项目。标准库正是编译器团队已有多年经验的代码库类型。

然而，团队并非孤立存在，实际上 API 设计和实现会相互影响。这仅仅是 Libs 团队和编译器团队之间的一种共识，旨在使标准库活动更加聚焦。

这些活动中是否有吸引你的？也许你有兴趣识别并将惯用法捕获为标准 API。如果是，你可以在这里找到 Libs 团队。也许你想在一个几乎所有 Rust 开发者都在使用的大型代码库上工作。如果是，你可以在这里找到编译器团队。也许你喜欢这两者之间的一切！无论如何，标准库总有适合你的地方。