提案需通过流程控制，避免过度开发造成不良后果。Rust创始人GraydonHoare就共享语言资源和处理社区中的个人压力提供了建议。本文作者GraydonHoare是Rust语言的创造者。众所周知，Rust最初是Mozilla员工GraydonHoare的一个私人项目。2009年，Mozilla开始赞助Rust，数名Mozilla员工参与了Rust语言的设计和开发。2013年8月，GraydonHoare辞去了Rust技术主管一职。需要说明的是，GraydonHoare表示，文章仅代表自己的观点和立场，与任何人无关，甚至不再表示自己是Rust的积极参与者，而且这些建议在很大程度上适用于很多项目。Rust只是一个例子，但这是年终总结的好时机。GraydonHoare也对Rust项目的发展轨迹感到非常满意，并撰写了这篇文章以使其保持健康并走上正轨。更重要的是，希望Rust能够避免他在作为“局外人”进行开发时观察到的问题。Rust创始人GraydonHoare表达了Rust发展需要注意的两个具体部分和改进建议。一个是需要共享技术文档和成品（Artifacts），尤其是语言定义本身，另一个是关注回到社区成员——个人，关注参与工作的社区个人的压力，GraydonHoare提到这些要及早控制，有计划地进行。GraydonHoare认为，任何由于缺乏控制机制而导致发展过快的事情最终都会导致不良后果，并列举了几个Rust项目限制变化率和增长率的控制案例。他提到，这对项目的成功有很大帮助。BorsQueue通常用于修改程序的正确性，而CraterRuns用于修正整个生态系统的正确性，而基于时间的版本发布（Time-basedreleases）也是流程控制之一，即用于决定是否放弃时间表或减少功能。此外，Rust添加了一些制度化程度较低但仍然重要的社区结构来管理参与项目的人员的成长，例如RFC流程，包括关于形式、内容、时间、参与者组合的讨论，以及何时讨论重大变更，治理模型也是控制方法之一，用于划分职责范围，必要时授予权限，参与者的角色和期望等。GraydonHoare认为Rust中还有两大领域缺乏功能管理.首先是语言本身的发展，需要更多的规范；二是人，即社区成员。GraydonHoare提到，当社区成员过于疲倦时，他们可能会做出错误的决定，社区也可能因为成员拥有的资源不均衡而发展成倾斜的，拥有特权、精力充沛、收入丰厚或其他优势。只有人才能跟上社区的发展。人们还常常为了赢得争论而缩小言论自由，成员因倦怠、表现不佳而离开项目，社区甚至可能因恶意指责、口头仇恨或挫折而分裂。为此，GraydonHoare提出了一些建议，认为Rust项目是时候暂停、反思、集思广益并实施一些控制措施了。他认为，最重要的是社区应该学会拥抱负面语言，并尝试接受负面和负面的意见，比如“Rust永远不会有某种功能”。只有冷静思考，才能获得长远的结果愿景。此外，社区还需要设置一些限制机制，找出编译器编译的代码行数、Bootstrap总耗时、AWS执行个体每日成本、数量等有意义的值类别系统中的推理规则。指标、开发机制来限制开发速度。然后是基于个人时间预算的活动限制——计算每个团队有多少时间可以不被耗尽，或者每个版本发布需要多少人力和时间，去掉超过这个时间范围就可以完成工作.项目维护团队应该对特定的讨论进行速率限制或提供冷静期，因为有时从外部来看，社区的整体讨论过于激烈，限制讨论是一种简单的“冷却”和重新聚焦的方式讨论回到主题，不受个人行为的影响。此外，应该成立一个额外的项目团队，主要负责审查其他团队的预算以实现“负载平衡”，GraydonHoare认为这对团队有帮助，让第三方而不是团队的大多数人成员判断事情的进展，因为大多数成员会因为他们预先设定的立场而对大多数事情说是。
