语言团队设计会议：成为成员的途径

本周，语言团队设计会议的主题是“成为成员的途径”。这篇博文给出了一个简短的总结；您也可以阅读会议纪要或观看录像。

本次会议的前提是，语言团队从来没有一个特别清晰的成为成员的途径 —— 也就是说，很难确切地说，如果你想成为语言团队的成员，应该采取哪些步骤。然而，随着向重大变更提案的转变，特别是项目组，我们开始看到这样一条途径的雏形。

在我们的讨论中，我们列出了一个相对完整的列表，我们认为这是“对语言团队成员的期望”。需要明确的是，这是所有可能的期望：许多成员在任何给定时间只有时间做这些事情的子集。

在适当的情况下领导项目组
在适当的情况下作为项目联络人
参与分类会议
参与设计会议
及时响应 rfcbot fcp 请求
建设性地参与并帮助促进 RFC 讨论、问题、PR 和其他基于 GitHub 的讨论
- 提供重要的技术要点
- 帮助推动讨论达成共识
- 理解和记录提出的立场和观点
监控并回复 Zulip 中的通信

成为成员途径的核心思想是，我们希望通过一些步骤，让我们看到人们在做我们期望语言团队成员所做的事情，并展示其品质，这样我们才能知道它是如何运作的（并让人们体验一下它的感觉）。

这表明，“成为成员的途径”可能看起来像这样

我们意识到，我们可以找到那些已经在做其中一些事情的人，并询问他们是否有兴趣加入语言团队。如果是这样，我们可以寻找机会来完成其他一些要点。

一点背景：项目组

我们没有过多地在博客上谈论项目组之类的想法，所以让我简单介绍一下背景。简而言之，我们的想法是，通过引入一个名为重大变更提案（MCP）的“预步骤”，来尽早“拦截” RFC 流程。（术语仍会随着我们在此处的实验而变化。）

其想法是，如果你有一个想要追求的想法，你可以提交一个 MCP 问题并描述高级细节。如果该想法引起了团队中某人的注意，我们将创建一个项目组来追求该想法，该成员担任语言团队联络人，而你（或其他人）担任组长。

一个项目组不必是一个庞大的人群。它甚至可能只有一两个人和一个专门的 Zulip 流。其想法是，该小组将制定设计空间并撰写 RFC；一旦 RFC 被接受，该小组还可以追求实施（尽管此时涉及的人员可能会发生变化），并有望一路将想法推向稳定。

我们讨论的一件事是项目组联络人的适当角色。如前一段所述，联络人基本上是团队的一名成员，他会关注设计并帮助让团队的其余成员了解最新情况。

但是我们意识到，如果我们将联络人限制为团队成员，那么这与“成为成员的途径”的想法不兼容，即人们可以“试运行”语言团队的活动。这也与一个核心目标有些不兼容，该目标是，不在团队中的人和在团队中的人的体验应该非常接近，并且我们在创建区别时应该小心。

因此，我们讨论了这样的想法，即联络人不必是团队成员，他们只需要是深入参与项目并可以信任为语言团队创建定期更新并让团队的其余成员了解最新情况的人即可。

特别是，这也可以是迈向正式语言团队成员资格的有用垫脚石 - 尽管不一定非得如此。即使人们没有太多时间或兴趣加入语言团队，让他们担任联络人也是有用的。

我们得出的结论是，我们将开始尝试“非团队成员联络人”，并且那些可能对该角色感兴趣的人可以私下联系 Josh Triplett 或我（nikomatsakis）。此外，我们将努力撰写“成为成员的途径”以及对团队成员的期望。