Linuxeden开源社区本文翻译自 Graydon 的个人博客：Rust 2019 and beyond: limits to (some) growth.
提案需要通过流程进行控制，以避免发展过快导致不良后果。Rust 创始人 Graydon Hoare 针对语言资源共享以及处理社区个体压力两部分提出建议。
本文作者 Graydon Hoare 是 Rust 语言创始人。众所周知，Rust 最初是 Mozilla 公司员工 Graydon Hoare 的私人项目。2009年 Mozilla 开始赞助 Rust，并有若干 Mozilla 员工参与 Rust 语言的设计和研发。2013年8月，Graydon Hoare 卸任 Rust 技术负责人职位。
需要说明的是，Graydon Hoare 表示文章仅代表其本人的观点和立场，与其他任何人无关，甚至不再是以 Rust 积极参与者的身份在表达，而且这些建议在很大程度上适用于许多项目。Rust 只是一个案例，不过目前恰好适合进行一次年终总结。
Graydon Hoare 对 Rust 项目的发展轨迹也非常满意，之所以写下这篇文章是为了保持它的健康，以及让它在轨道上如期行驶。更重要的是，希望 Rust 能避免他以“局外人”身份进行开发时观察到的这些问题。
Rust 创始人 Graydon Hoare 对 Rust 的发展，表达了两个具体需要注意与改善建议的部分，一是必须要共享技术文件与成品(Artifacts)，特别是语言定义本身，再来则是要把注意力放回到社区成员 —— 个体身上，关注参与工作的社区个人的压力，Graydon Hoare 提到，这些必须要及早控制，以有计划的方式进行。
Graydon Hoare 认为，任何事物因缺乏控制机制而发展过快，最终都会导致不好的后果，并列举了几个 Rust 项目对变化率与增长率进行限制的控制案例。他提到，这对于项目的成功有很大的帮助，像 Bors Queue 通常是用来对程序范围内的正确性进行修改，而 Crater Runs 则是用来修正整个生态系统的正确性，而基于时间的版本发布(Time-based releases)也是流程控制之一，用来决定是否需要放弃遵守时间表，或者是削减功能。
另外，Rust 还增加了一些制度化不太明显，但仍十分重要的社区结构，以管理参与项目的人员成长，例如 RFC 流程，包括关于形式、内容、时间、参与者组合以及讨论重大变化时讨论的规则等，另外，治理模型也是其中的一种控制方式，用于划分责任区域、必要时的权限授予、参与者的角色和期望等。
Graydon Hoare 认为，目前 Rust 仍有两大领域缺乏功能性的管理，第一是语言的发展本身，这需要有更多的规范；第二是人，亦即社区成员。Graydon Hoare 提到，当社区成员过于疲惫，可能会做出糟糕的决定，而且社区也可能因成员拥有的资源不均而导致发展偏斜，具有特权、精力充沛、收入丰厚或是其他优越条件的人，才能跟上社区的发展。人们也常为赢得争论，使得言论自由变得狭隘，成员也会因为倦怠、表现不佳而离开项目，社区甚至会因为恶意指责、语言仇恨或挫折而分裂。
为此，Graydon Hoare 提出了几项建议，他认为 Rust 项目现在应该暂停、反思、集思广益并执行一些控制措施。他认为最重要的是，社区要学会拥抱负面的语言，试着接纳消极、负面的意见，像是“Rust 永远不会有某功能”这样的话语，唯有沉住气冷静地思考，才能获得长远的视野。
除此之外，社区还需要设立一些限制机制，针对诸如编译器编译代码行数、Bootstrap 的总时间数、每日 AWS 执行个体的花费成本、类别系统中推理规则数量等，找出有意义的指标，制定机制以限制发展速度。再则就是基于个人时间预算的活动限制 —— 计算出在不疲惫的情况下，每个团队有多少可用的时间，或是每个版本的发布需要耗费多少人力和时数，并移除超过这个时间范围可以做的工作。
项目维护团队应在特定的讨论上加以速率限制或是提供冷静期，因为有时从外部看来，社区的整体讨论过于激烈，而限制讨论是简单的可以“降温”的方式，能让讨论焦点重新回到主题上，而不会被个人行为影响。另外，还应设置一个额外的项目团队，主要负责审核其他团队的预算以达“负载均衡”，Graydon Hoare 认为这对于团队是有帮助的，让第三方而不是团队中的大多数成员来判断事情的进展，因为大多成员会因为抱着预设的立场而对大多数的事情都说好。
转自 https://www.oschina.net/news/103234/rust-2019-and-beyond