Rust創造者Graydon Hoare：社群應限制成長速度

Rust創造者Graydon Hoare對Rust的發展，表達了兩個具體需要注意與改善建議的部分，一是必須要共享技術文件與成品（Artifacts）特別是語言定義本身，再來則是要把注意力放回人身上，關注參與工作社群個人的壓力，Graydon Hoare提到，這些必須要及早控制，以有計劃的方式進行。

Graydon Hoare認為，任何事物因缺乏控制機制，而發展過快，最終都會導致不好的結果，並列舉了幾種，Rust專案對變化率與成長率進行限制的程序控制形式，他提到，這對於專案的成功是有很大幫助的，像是Bors Queue通常是用來對程式範圍內的正確性進行修改，而Crater Runs則是用來修正整個生態系的正確性，而基於時間的版本發布也是流程控制之一，用來決定放棄時間表抑或是閹割功能。

另外，Rust還增加了一些機制化較低，但仍然重要的社群結構，以管理參與專案的人員成長，例如RFC流程，包括關於形式、內容、時間、參與者組合以及討論重大變化時討論的規則，另外，治理模型也是其中一種控制，畫分責任區塊、必要時的階層授權、參與者的角色和期望等。

Graydon Hoare認為，目前Rust仍有兩大領域缺乏功能性的管理，第一是語言的發展本身，需要有更多規範，第二是人，也就是社群成員。Graydon Hoare提到，當社群成員過於疲憊，就可能做出糟糕的決定，而且社群也可能因成員擁有的資源不均導致發展偏斜，具有特權、精力充沛、收入豐厚或是其他優越條件的人，才能跟上社群的發展。人們也常為贏得爭論，使得話語發展變得狹隘，成員也會因為倦怠、表現不佳而離開專案，社群或因為惡意指責、仇恨語言或挫折而分裂。

Graydon Hoare提出了幾項建議，他認為Rust專案現在應該暫停、反思、集思廣益並實施一些控制措施。他認為最重要的是，社群要學會擁抱負面的語言，試著接納消極、負面的意見，像是Rust永遠不會有某功能這樣的話語，沈住氣忠實地思考，才能獲得長遠的視野。

另外，也要設定一些限制機制，針對諸如編譯器編譯程式碼行數、Bootstrap總時數、每日AWS執行個體的成本花費、類別系統中推理規則數量等，找出有意義的指標，制定機制以限制發展速度。再來是基於個人時間預算的活動限制，計算出在不疲憊的情況下，每個團隊有多少可用時數，或是每個版本釋出需要多少個人力時數，並移除超過這個時間範圍可以做的工作。

主持團隊應在特定討論上加以限制速率或是提供冷靜期，因為有時從外部看來，社群整體討論過於激烈，而限制討論是簡單可以降溫的方式，能讓討論焦點重新回到主題上，而不會被個人行為影響。也應該設置一個額外的專案團隊，負責審核其他團隊的預算以達負載平衡，Graydon Hoare認為這對於團隊是有幫助的，讓第三方來判斷事情的進展，而不是大多數在參加團隊時，預設立場對大多數的事情都說好。