本文作者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 認為這對於團隊是有幫助的，讓第三方而不是團隊中的大多數成員來判斷事情的進展，因為大多成員會因為抱著預設的立場而對大多數的事情都說好。

本文翻譯自Graydon的個人博客：Rust 2019 and beyond: limits to (some) growth.