语言团队设计会议：成员之路

本周语言团队设计会议的主题是“成员之路”。这篇博客文章提供了简要概述；您也可以阅读会议记录或观看录像。

会议的前提是语言团队从未有过特别清晰的*成员之路*——也就是说，如果想成为语言团队的成员，很难确切地说应该采取什么样的步骤。然而，随着转向重大变更提案，尤其是项目组，我们开始看到这样一条道路的雏形。

作为讨论的一部分，我们提出了一个相对完整的列表，列出了我们认为“对语言团队成员的期望”。需要明确的是，这是一整套可能的期望：许多成员在任何特定时间只能做其中的一部分。

酌情领导项目组
酌情担任项目联络人
参加筛选会议
参加设计会议
及时回复 rfcbot 的 FCP 请求
建设性地参与并协助促进 RFC 讨论、议题、PR 以及其他基于 GitHub 的讨论
- 提供重要的技术观点
- 帮助推动讨论达成共识
- 理解并记录提出的立场和观点
监控并回复 Zulip 中的交流

成员之路的核心思想是，我们希望有一系列步骤，让我们能够看到人们做着我们期望语言团队成员做的事情并展示出相应的品质，这样我们就能判断它是如何运作的（也让人们能够体验它的感觉）。

这表明“成员之路”可能看起来像这样

我们意识到，我们可以识别那些已经在做其中一些事情的人，并主动询问他们是否对语言团队成员资格感兴趣。如果他们感兴趣，我们可以寻找机会来完成其他一些事项。

一点背景知识：项目组

我们还没有写很多关于项目组之类的博客，所以让我提供一点背景知识。简而言之，其想法是尝试通过引入一个称为重大变更提案（MCP）的“预备步骤”来更早地“拦截”RFC 流程。（此处术语仍在实验中，可能会有变化。）

想法是，如果您有一个想要推进的点子，可以提交一个 MCP 议题并描述高层级的细节。如果这个点子引起了团队内某位成员的注意，我们将创建一个项目组来推进这个点子，该成员将担任语言团队联络人，您（或其他人）担任项目组负责人。

一个项目组不一定是很多人组成的大团队。它甚至可能只有一两个人，配有一个专门的 Zulip 流。想法是该项目组将研究设计空间并撰写 RFC；一旦 RFC 被接受，该项目组也可以继续推进实现（尽管那时参与人员可能会变化），并希望将这个点子一路推向稳定。

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

但我们意识到，如果我们将联络人仅限于团队成员，那么这与“成员之路”的想法不符，因为成员之路允许人们“试运行”语言团队的活动。这在某种程度上也与一个核心目标不符，即不在团队中的人与在团队中的人的体验应该非常接近，并且我们在制造区别时应该小心。

因此，我们讨论了联络人不一定非要是团队成员的想法，他们只需要是深度参与项目的人，并且能够信任他们定期为语言团队创建更新，并让团队其他成员随时了解情况。

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

我们得出结论，将开始实验“非团队成员联络人”，对这个角色可能感兴趣的人可以私下联系 Josh Triplett 或我（nikomatsakis）。此外，我们将努力撰写关于“成员之路”以及对团队成员的期望的文档。