• 提案需要通過流程進行控制，以避免發展過快導致不良后果。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 認為這對于團隊是有幫助的，讓第三方而不是團隊中的大多數成員來判斷事情的進展，因為大多成員會因為抱著預設的立場而對大多數的事情都說好。